Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2003.04.28;
Скачать: CL | DM;

Вниз

Получить одним запросом данные из нескольких таблиц   Найти похожие ветки 

 
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;
Скачать: CL | DM;

Наверх




Память: 0.5 MB
Время: 0.021 c
3-91230
mikl2002
2003-04-10 13:31
2003.04.28
InterBase + Linux + FIBPlus


3-91213
Z_man7777
2003-04-10 15:35
2003.04.28
Возврат данных из процедуры.


14-91528
passm
2003-04-10 17:07
2003.04.28
Windows XP & LPT1 привелегии пользователей ??


3-91162
SiJack
2003-04-09 11:54
2003.04.28
Экспорт BD


1-91372
Бегинер
2003-04-16 10:33
2003.04.28
Math