Два LEFT JOIN в SELECT'е

Удав

Конечно.
Зачем объединять мух с котлетами? :wink:

zsap

Подниму старую тему

Вольдемар написал(а):

Для построения отчёта мне нужно связать эти табдицы примерно так:

Code:

select xxx  into yyy
  from face
  left join role  on face~id = role~face_id
  left join dover on face~id = dover~face_id and
                     role~id = dover~role_id.

на такой селект САП ругается: к одной таблице может быть тока 1 аутер джоин. (что, собственно, правильно и ожидаемо)
Посоветуйте, что мне надо сделать, чтоб получить обвязку именно 3-х таблиц

Проблема стара как мир, думаю каждому хоть раз приходилось ломать голову над тем, как объединить 3 и более таблиц в LEFT JOIN, где 3-я таблица зависимая от первых двух. Обычно в таких случаях разбивают селект на несколько селектов попроще, но такое решение удобным не назовешь. А есть ведь простой выход - пользоваться ракурсами. Например, обозначенный выше селект можно переделать так

Code:

select xxx  into yyy
  from face
  left join role  on face~id = role~face_id
  left join role_dover_v on face~id = role_dover_v~face_id                      

Тут role_dover_v - ракурс, объединяющий таблицы role и dover
Сложнее когда на таблицу, присоединяемую через LEFT JOIN нужно сделать ограничение по select-option, хотя и тут можно обойтись одним селектом, но это уже другая тема

Удав

zsap написал:

Проблема стара как мир, думаю каждому хоть раз приходилось ломать голову над тем, как объединить 3 и более таблиц в LEFT JOIN, где 3-я таблица зависимая от первых двух. Обычно в таких случаях разбивают селект на несколько селектов попроще, но такое решение удобным не назовешь.

Почему?
Это проблема осталась только в головах тех, кто не понял, что SAP реализует 3-х звенную архитектуру клиент-сервер и не знает, почему плохо нагружать сервер БД

zsap написал:

А есть ведь простой выход - пользоваться ракурсами. Например, обозначенный выше селект можно переделать так

Code:

select xxx  into yyy
  from face
  left join role  on face~id = role~face_id
  left join role_dover_v on face~id = role_dover_v~face_id                      

А что, в SE11 можно сделать ракурс с left join?

zsap

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

А что, в SE11 можно сделать ракурс с left join?

Обычный ракурс БД вполне сгодится )

Удав

zsap написал:

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

А что, в SE11 можно сделать ракурс с left join?

Обычный ракурс БД вполне сгодится )

Так он же не left join, поэтому первоначальное условие с 2-мя left join не будет выполняться: выберутся только те доверенности, в для которых есть привязка к ролям. Если доверенность выдана на человека и не привязана к роли, то она не выберется в ракурсе.

zsap

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

Если доверенность выдана на человека и не привязана к роли, то она не выберется в ракурсе.

Согласен, но из постановки задачи это вроде бы и не требовалось

Вольдемар написал(а):

т. е. доверенность выдаётся лицу на исполнение определённой роли на указанный срок

Хотя и тут без проблем все выбирается одним селектом, правда такие доверенности без роли придется выбирать в отдельное поле внутренней таблицы

Code:

select xxx  into yyy
  from face
  left join role  on face~id = role~face_id
  left join role_dover_v on face~id = role_dover_v~face_id   
  left join dover on dover~face_id = face~id  and      "доверенности без роли 
                  dover~role_id =  space.

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

Это проблема осталась только в головах тех, кто не понял, что SAP реализует 3-х звенную архитектуру клиент-сервер и не знает, почему плохо нагружать сервер БД

Разделение одного селекта на несколько далеко не всегда способствует разгрузке БД. Если таблицы большие - только добавит тормозов, т.к. второй и последующие запросы скорее всего придется вызывать в цикле по каждой записи из первого запроса. FOR ALL ENTRIES не решает суть проблемы - в БД все равно пойдет куча селектов
off. клиент-сервер это как раз таки 2х звенная архитектура, а 3х звенная - это Клиент-Сервер приложений-Сервер БД

Удав

zsap написал:

Разделение одного селекта на несколько далеко не всегда способствует разгрузке БД. Если таблицы большие - только добавит тормозов, т.к. второй и последующие запросы скорее всего придется вызывать в цикле по каждой записи из первого запроса. FOR ALL ENTRIES не решает суть проблемы - в БД все равно пойдет куча селектов

Способствует, т.к. серверу БД не нужно будет производить сложный анализ стратегии выборки данных. Как правило условия выборки в FOR ALL ENTRIES строятся на индексах

zsap написал:

off. клиент-сервер это как раз таки 2х звенная архитектура, а 3х звенная - это Клиент-Сервер приложений-Сервер БД

Таки не надо придираться :lol:

zsap

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

Способствует, т.к. серверу БД не нужно будет производить сложный анализ стратегии выборки данных. Как правило условия выборки в FOR ALL ENTRIES строятся на индексах

Спор ни о чем. Я ведь не говорю что запросы везде и всегда стоит лепить в кучу. В каждом конкретном случае оптимальная стратегия будет своя. Говорить что какой-то определенный подход на 100% работает быстрее или меньше грузит БД думаю не совсем верно. Например, в "тяжелых" запросах время анализа стратегии не играет существенной роли

__Gennady

С FOR ALL ENTRIES вообще имеет смысл поиграться согласно ноте 48230. Можно заметно повысить производительность. По умолчанию делается один запрос на каждые 5 записей во внутренней таблице.

Удав

zsap написал:

В каждом конкретном случае оптимальная стратегия будет своя.

Конечно.

zsap написал:

Например, в "тяжелых" запросах время анализа стратегии не играет существенной роли

Время анализа - нет, результат анализа - да.
Например если в качестве базовой выберется выберется неверная таблица и выборка будет идти по неправильному индексу.

Предлагаю закончить оффтоп :pivo:

Николай Рыжов

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

Способствует, т.к. серверу БД не нужно будет производить сложный анализ стратегии выборки данных. Как правило условия выборки в FOR ALL ENTRIES строятся на индексах

Что-то мне подсказывает, что оптимизатор современных БД куда как эффективнее отработает, нежели закат солнца вручную через промежуточные таблицы и FOR ALL ENTRIES с морем раундтрипов до БД. Аналогичным образом бесит отстутствие возможности иcпользовать поля внешне присоединенной таблицы с SELECT-OPTIONS. Уже несколько раз нарывался, когда в выборке по цепочке документов (которая может быть неполной) приходится извращатся с последовательностью запросов, в зависимости от выбранных критериев поиска.

Короче, не надо приписывать SAP благих мотивов, которые подвигли на такие ограничения OPEN SQL. Скорее уж тяжкое наследство зоопарка SQL древних времен.

ArmAnn

Николай Рыжов написал(а):

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

Способствует, т.к. серверу БД не нужно будет производить сложный анализ стратегии выборки данных. Как правило условия выборки в FOR ALL ENTRIES строятся на индексах

Что-то мне подсказывает, что оптимизатор современных БД куда как эффективнее отработает, нежели закат солнца вручную через промежуточные таблицы и FOR ALL ENTRIES с морем раундтрипов до БД.

Вот не факт... у оптимизаторов тоже хватает своих глюков, и как тут будет эффективнее - предсказать сложно. Но простые запросы более предсказуемы и их легче отлаживать

Николай Рыжов написал(а):

Аналогичным образом бесит отстутствие возможности иcпользовать поля внешне присоединенной таблицы с SELECT-OPTIONS. Уже несколько раз нарывался, когда в выборке по цепочке документов (которая может быть неполной) приходится извращатся с последовательностью запросов, в зависимости от выбранных критериев поиска.
Короче, не надо приписывать SAP благих мотивов, которые подвигли на такие ограничения OPEN SQL. Скорее уж тяжкое наследство зоопарка SQL древних времен.

Но и не надо этих мотивов вычеркивать

SAP рекомендует по возможности переносить нагрузку с сервера БД на сервера приложений, и вполне вероятно это одна из причин по которой они не хотят расширять возможности Open SQL

zsap

Николай Рыжов написал(а):

Аналогичным образом бесит отстутствие возможности иcпользовать поля внешне присоединенной таблицы с SELECT-OPTIONS

Возможность есть, правда через одно место ))

Code:

if so_name[] is initial.
   is_so_name_initial = 'X'.
endif.

select xxx  into yyy
  from role
  left join face on face~id = role~face_id
where exists ( select * from face as f 
                where f~id = role~face_id and
                      f~name in so_name
             )
or exists ( select * from zdual where x = is_so_name_initial).

Для этого нужна вспомогательная таблица zdual из одного столбца X и одной строки со значением 'X'. Таблица, присоединяемая через left join должна связываться по полному ключу, иначе в выборке могут появиться лишние записи

Николай Рыжов

ArmAnn написал:

Вот не факт... у оптимизаторов тоже хватает своих глюков, и как тут будет эффективнее - предсказать сложно. Но простые запросы более предсказуемы и их легче отлаживать

Отлаживать легче, факт. Но чтобы запрос "вручную" был более эффективен, чем эквивалентный запрос БД - не видел ни разу, да и просто не верю. Глюки с паланами запроса были пару раз за несколько лет, лечилось пересчетом статистики за минуту.

ArmAnn написал:

Но и не надо этих мотивов вычеркивать

SAP рекомендует по возможности переносить нагрузку с сервера БД на сервера приложений, и вполне вероятно это одна из причин по которой они не хотят расширять возможности Open SQL

Ну, никто ж не предлагает писать хранимые процедуры на БД

. А вот что касаемо выборки данных - современные БД справляются с этим исключительно эффективно. Да и надо-то всего-то - нормально разобраться с внешними джойнами, да добавить наконец-то выражения в логические условия.

Николай Рыжов

zsap написал:

Возможность есть, правда через одно место ))

Да, неплохо. Как говорится, не можешь - научим, не хочешь заставим

. Однако не хотелось бы вот мучить тех, кто потом это будет поддерживать.

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

Два LEFT JOIN в SELECT'е

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