Запрос с двумя подчиненными таблицами

HOME_X

Доброго дня господа !

Имею исходные таблицы
T1
F1 F2
1 A
2 B

T2
F1 F2 F3
1 C 3
2 D 4

T3
F3 F4
3 E
5 F

Необходимо получить результат
T1.F1 T1.F2 T2.F2 T3.F4
1 A C E
2 B D Null

Скрипт может выглядит
select T1~F1
T1~F2
T2~F2
T3~F4
from T1
left join T2 on T2.F1=T1.F1
left join T3 on T3.F3=T2.F3
Hе могу установить двойное взаимо-подчинение объектов.

Подскажите как правильно изобразить .

P.S. - Native Sql пользоваться ПОЛИТИЧЕСКИ нельзя ......

Удав

HOME_X написал(а):

Hе могу установить двойное взаимо-подчинение объектов

Конечно не можете, если таблица T2 не будет основной.

Если таблица T1 должна быть основной, то задача решается в 3 шага:
1.T2 +left join T3 в it1
2.Получение данных из T1 в it2
3.Объединение данных из it2 и it1

HOME_X

Принято !
Так и делаю, полагал может есть системные решения
и по их незнанию - занимаюсь таким слепливание.

Спасибо !

Parazit

К сожалению на умозрительном примере и рекомендации могут быть отдаленные от реалий. А на практике, на примере Удава , если за T2 принять таблицу MARA (справочник материалов с огромной номенклатурой), то уже на первом шаге может "лопнуть" it1, т.е. получим дамп из-за нехватки памяти (случай из жизни).

Я предпочитаю придерживаться подхода без внутренних таблиц, ненужные данные не нужно и брать!
Я бы разбил запрос на части:
1. T1 join T2 left join T3 ...into itab
2. T1 not in T2 ...appending itab

Однако, в реальности могут быть и кластерные таблицы, тогда плакали наши джойны, всё через вн. таблицы.

Удав

Parazit написал:

А на практике, на примере Удава , если за T2 принять таблицу MARA (справочник материалов с огромной номенклатурой), то уже на первом шаге может "лопнуть" it1, т.е. получим дамп из-за нехватки памяти (случай из жизни).

Я предпочитаю придерживаться подхода без внутренних таблиц, ненужные данные не нужно и брать!
Я бы разбил запрос на части:
1. T1 join T2 left join T3 ...into itab
2. T1 not in T2 ...appending itab

В твоем случае упадет, если MARA назначить T1

Правильное решение об объединении таблиц можно принять только после того, как они известны.

Parazit

Удав написал(а):

Parazit написал:

...
Я бы разбил запрос на части:
1. T1 join T2 left join T3 ...into itab
2. T1 not in T2 ...appending itab

В твоем случае упадет, если MARA назначить T1

Правильное решение об объединении таблиц можно принять только после того, как они известны.

В моем варианте можно обойтись без внутренних таблиц (select... endselect), просто показал новичку "appending" (вдруг не знает).
Во-вторых, если уж T1 основная, то я подразумеваю хоть какой то разумный "where". А вот для T2 уже "join" является ограничением, т.е. выберется только нужное. В твоем случае это ограничение отпадает, да и само существование п.3 означает избыточность данных в любой из вн. таблиц.
В третьих, Удав, не заводи баркас!

Ты свой вариант показал, я свой. Пусть выбирает, что ему по душе.

Удав

Parazit написал:

если уж T1 основная, то я подразумеваю хоть какой то разумный "where".

Я тоже подразумевал разумный where для T2

Parazit написал:

В третьих, Удав, не заводи баркас!

HOME_X

Принято - учту при отработке !

Немного смутили СКОБКИ из примера
Полагал что аналогичный вариант также приемлем для диррективы LEFT JOIN

Code:

SELECT c~carrname p~connid f~fldate 
       INTO CORRESPONDING FIELDS OF TABLE itab 
       FROM ( ( scarr AS c 
         INNER JOIN spfli AS p ON p~carrid   = c~carrid 
                              AND p~cityfrom = p_cityfr 
                              AND p~cityto   = p_cityto ) 
         INNER JOIN sflight AS f ON f~carrid = p~carrid 
                                AND f~connid = p~connid ). 

Спасибо !

Удав

HOME_X написал(а):

Полагал что аналогичный вариант также приемлем для диррективы LEFT JOIN

Нет, неприемлим.
Как и то, что в примере нет ограничения выборки для основной таблицы sflight, которую к тому же засунули в join.

HOME_X

А простейшие действия - типа "+" ,"-", "&&"
выполнять над полями можно ?

Удав

Нельзя, да и зачем?

БД нужна R/3 только для хранения и выборки данных.
Большая часть возможностей современных СУБД интерфейсом БД SAP не используется. Причины описал Parazit в другом сообщении.

HOME_X

Удав написал(а):

Нельзя, да и зачем?

Чтобы разгрузить пользовательский код.

Удав написал(а):

Большая часть возможностей современных СУБД интерфейсом БД SAP не используется.

Т.е. операция SELECT - это просто импорт данных + некоторые легкие операции

Верно понимаю ?

Удав

HOME_X написал(а):

Т.е. операция SELECT - это просто импорт данных + некоторые легкие операции

Верно понимаю ?

Да.

HOME_X

Спасибо ....

P.S. ФУФ .... печально !

Пономарев Артем

Такую выборку можно записать в один запрос даже с учетом крайне ограниченного синтаксиса Open SQL. Только его эффективность будет ниже плинтуса. И структура результирующей таблицы будет избыточной.
Можно джойнить таблицы сами с собой и использовать подзапросы NOT IN. Но это уже БДСМ какой-то выйдет

Правила форума

Запрос с двумя подчиненными таблицами

Кто сейчас на конференции