Проблемма с LEFT JOIN...

Primat

Могу чуть по подробней:
ZDTAB_1 = 11 289 записей
ZDTAB_2 = 249 662 записей
ZDTAB_3 = 249 701 записей

SELECT
TAB_1~f1
TAB_2~g1
TAB_2~g2
TAB_2~g3
TAB_3~s1
INTO (rf1, rg1, rg1, rg1, rs1)
FROM ZDTAB_1 AS TAB_1
JOIN ZDTAB_2 AS TAB_2
ON TAB_1~f1 = TAB_2~g4
LEFT JOIN ZDTAB_3 AS TAB_3
ON TAB_3~s2 = TAB_2~g3

WHERE TAB_1~f2 like '2008%'.

if rs1 = SPACE. " TAB_3~s1 <> SPACE

endif.

ENDSELECT.

Jelena

Моха написал(а):

А никто не знает, почему такое ограничение?

Цитата:

Since not all of the database systems supported by SAP themselves support the standard syntax and semantics of the left outer join, the syntax has been restricted to those cases that return the same solution in all database systems.

https://www.sdn.sap.com/irj/sdn/thread?threadID=495617

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

Могу чуть по подробней

Вообще-то главная отсутствующая подробность тут - это primary key таблиц...

Кроме того, IMHO имеет значение не только общее кол-во записей в таблице, но и сколько записей вы ожидаете получить в результате выборки. Например, конструкция SELECT ... ENDSELECT оправдана если вы ожидаете выбрать что-то порядка сотни тысяч записей. А если, скажем речь идет о паре сотен, то я бы рекомендовала SELECT INTO TABLE. Соответственно потом просто делается DELETE FROM TABLE WHERE s1 = space и все дела.

Art386

Моха написал(а):

Jelena написала:

Если вы присоединяете таблицу с помощью LEFT JOIN (т.е. у вас это ZDTAB_3), то никакие поля из нее не могут фигурировать в WHERE.

А никто не знает, почему такое ограничение? В других реализациях SQL вроде бы такого нет.
Т.е. есть ли некий практически разумный смысл в этом ограничениии или просто так исторически сложилось?

А в OpenSQL вобще есть определенные ограничения по сравнению со стандартом SQL для совместимости с разными СУБД, ведь запросы OpenSQL преобразуются в родной SQL СУБД интерфейсом БД на ApServ. Типа чтобы система встала на всякие различные СУБД, которые могут не поддерживать все возможности стандарта.

Типа того.

s_ss

Jelena написала:

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

Все таблицы имеют >= 250 000 записей и выбрасывать какое-то условия, чревато увеличением времени отработки запроса.

Ну, в таком случае наверное имеет место, пардон, ситуация "как не ложись - все равно отымеют". Кстати, раз уж таблицы Z, то может вообще надо бы их дизайн пересмотреть?

Интересно посмотреть как вы будете пересматривать дизайн таблицы на работающем проекте :lol:

.

Цель, я так понял, состоит в том, чтобы получить результат по запросу порядка 10 или 100

По поводу 3-х вариантов.
1. бОльшее количество записей - зло. Выборка большОго количества записей (порядка 10000) во внутреннюю сильно грузит систему. Время слишком большое.
2. Отдельный запрос - тоже нехорошо. Цикл по 250 000 записям и запрос на каждую из них в таблицу из 250 записей - Это просто писец.
3. Подзапрос - меньшее зло из вышеперечисленных. Т.к. по времени наиболее оптимален.
Есть еще 4-й вариант с Native SQL(как уже раньше говорилось) - это уже интересно с точки зрения времени выполнения

.

Дальше можно не читать :lol:

Как там товарищи ни говорят по 3-х ступенчатость системы, но нужно понимать, что сервер базы данных куда более лучше справится с правильным запросом. Чем потом иметь секас на сервере приложений с большой внутренней таблицей и кучей маленьких запросов. Спросить это у более опытных людей, скажем, кто работал на Oracle. Они вам покажут запросы на 10 килобайт, в котором стока логики заложено, что вам придется писать прогу на abap на 1000 строк

Сорри за оффтоп :lol:

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

Проблемма с LEFT JOIN...

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