Форум: "Базы";
Текущий архив: 2003.04.28;
Скачать: [xml.tar.bz2];
ВнизПолучить одним запросом данные из нескольких таблиц Найти похожие ветки
← →
paxer (2003-04-04 17:54) [0]Задача такая: есть таблице А поле а.TableName. В него пишется имя таблицы, из которой нужно получить поле b.Main где a.NumB=b.Num. Например:
SELECT a.TableName, b.Main
FROM a,b
WHERE a.Num=b.Num
Проблема в том, что b - имя таблицы, которое надо взять из a.TableName.
← →
NickBat (2003-04-04 18:10) [1]А более подробно о задаче? Может не стоит огород городить?
← →
paxer (2003-04-04 18:18) [2]Есть много справочников. Таблица А - это что-то вроде таблицы проводок. В поле a.TableName хранится название таблицы справочника, в Num таблицы А хранится номер записи из этой таблицы (B).
Если кто знает 1С, то это как бы моделирование типа Неопределенный.
Справочников может быть неограниченное количество.
← →
Johnmen (2003-04-05 03:22) [3]Ты подумай, а надо ли тебе погружаться в этот гимор ? Ты что, создаешь конструктор ?
Вот придет MsGuns © и прочистит тебе мозги :)))
От себя могу добавить, что система, предполагающая неопределенное кол-во справочников (а по сути, неопределенное кол-во сущностей), есть средство разработки (набор кубиков или конструктор, как было сказано выше). Впрочем, чем и является 1С.
← →
ЮЮ (2003-04-05 03:28) [4]Только динамически и ч/з Union:
1) Oпределить сколько справочников потребуется для результирующего запроса:
qTables: Select distinct NUM from a where ...
2) динамически создавать запрос, объединяя с помощью UNION
[UNION]
SELECT a.*, b....
FROM a, <TableName> b
WHERE a.Num= <NUM> and ...
В случае такой идиотской (сорри Неопределенной в стиле 1С) схемы данных не лучше ли сложить все "справочники" в одну таблицу
← →
paxer (2003-04-06 12:49) [5]Johnmen © Ты подумай, а надо ли тебе погружаться в этот гимор ? Ты что, создаешь конструктор ?
Вот придет MsGuns © и прочистит тебе мозги :)))
Я и создаю конструктор. А мозги пусть почистят, я послушаю. Очень часто можно услышать полезные мысли.
ЮЮ ©В случае такой идиотской (сорри Неопределенной в стиле 1С) схемы данных не лучше ли сложить все "справочники" в одну таблицу
Насчет идиотской не знаю, но в 1С с типом Неопределенный работать очень удобно. Будете отрицать - не поверю. На 1С я пишу уже 4 года.
Все "справочники" сложить в одну таблицу нельзя, разная структура (если я правильно понял слово "сложить").
Может кто что подскажет, может у кого-то есть какие-то еще идеи?
← →
ЮЮ (2003-04-07 05:16) [6]>с типом Неопределенный работать очень удобно. Будете отрицать - не поверю. На 1С я пишу уже 4 года
Тогда проясни для неработающих с 1С, что означает "неопределенность" на реальном примере
P.s. кроме наезда на "неопределённость" был и совет по SQL, не заметил?
← →
paxer (2003-04-07 10:51) [7]ЮЮ © >>"Неопределенность" как она сделана в 1С выглядит следующим образом: проводки лежат в одном файле. В плане счетов для каждого счета может быть разная аналитика (для 31 - расчетные счета фирмы, для 63 - контрагенты). Ссылка на аналитику первого уровня (в 1С может быть до 5 уровней) лежит в одном поле. Но для разных счетов это поле интерпретируется по разному, соответсвенно в журнале проводок (dbFrid) для проводки со счетом 31 отображается название р/с фирмы, а для 63-название контрагента. По всей видимости для каждой строки (записи) таблицы проводок для каждого такого субконто выполняется дополнительный запрос (поиск в DBF).
Твой совет я понял следующим образом: выполняем первый запрос, в котором определяем, сколько справочников нам понадобится.
Во втором запросе мы для делаем примерно следующее:
SELECT a.TableName, b.Main, c.Main ...
FROM a,b,c...
WHERE a.Num=b.Num and a.Num=c.Num ...
т.е. не смотрим, на какую таблицу мы ссылаемся реально, а получаем Main для всех возможных таблиц.
(WHERE надо поменять на LEFT JOIN)
Может я понял чего-то не так?
← →
ЮЮ (2003-04-08 04:03) [8]Не совсем. Раз уж речь шла одинамическом запросе, то я хотел ограничить кол-во блоков UNION только реально необходимым.
Но в принципе, можно это и не делать, а предусмотреть сразу полный запрос.
>т.е. не смотрим, на какую таблицу мы ссылаемся реально, а получаем Main для всех возможных таблиц.
(WHERE надо поменять на LEFT JOIN)
Как раз наоборот:
отбираем только те записи, ссылка у которых соответствует 1-ой таблице:
SELECT a.*, b.Name
FROM a, <Фирмы> b
WHERE a.Num= 31
Добавляем записи. ссылка у которых соответствует 2-ой таблице:
UNION
SELECT a.*, b.Name
FROM a, <Контрагенты> b
WHERE a.Num= 63
И т.д.
← →
paxer (2003-04-08 13:06) [9]По всей видимости я неточно поставил задачу. Надо выбрать все записи таблицы А. Для всех записей, где a.NumB не равно нулю, получить поле B.Main где B-таблица, имя которой задано в а.TableName. В таблицах B записи где b.Num=0 осутствуют.
В вопросе надо переделать пример запроса:
SELECT a.*, b.Main
FROM a LEFT JOIN b ON a.NumB=b.Num
Прошу прощения за неточный вопрос.
← →
ЮЮ (2003-04-09 03:47) [10]Да нет, вопрос совершенно ясен, имя таблицы хранится в полях таблицы БД и хочется его использовать в запросе, но это невозможно.
В тексте запроса имя таблицы должно стоять ЯВНО, а не может быть выбрано из полей записи.
Поэтому выход один (его я и приводил):
1) Выбрать только те записи из А, у которых в TableName указана одна и та же таблица, например B1, и связать их нормальным запросом
SELECT a.*, b.Main
FROM a LEFT JOIN B1 b ON a.NumB=b.Num
WHERE a.TableName = "B1"
2)
Сделать аналогично для записей, соответствующих таблице B2, объединив с записями из предыдущего запроса:
SELECT a.*, b.Main
FROM a LEFT JOIN B2 b ON a.NumB=b.Num
WHERE a.TableName = "B2"
3) и т.д.
И, наконец, понять, что такой подход вряд ли соответствует теории и практике реляционных баз данных
← →
Anatoly Podgoretsky (2003-04-09 08:05) [11]Всегда можно построить запрос динамически
SQL.Text := "SELECT a.TableName, " + BName + ".Main" +
"FROM a," + BName +
"WHERE a.Num="+ BName + ".Num";
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.04.28;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.009 c