Меняющийся тип соединения таблиц

[Xardas]

Доброго времени суток.

Имеется класс с большим количеством запросов вида

select tbl1
exists join tbl2
where tbl2.field1 == tbl1.field1

Сейчас возникла необходимость модифицировать данный код:
Если значение некоторой логической переменной истина, то соединение таблиц должно производиться с помощью exists join.
Если значение этой же логической переменной ложь, то соединение должно производиться с помощью notexists join.

Можно ли произвести данную модификацию? Вариант

if (flag)
  select...
else
  select...

не устраивает, поскольку код будет раздут до неимоверных размеров с дублированием операторов, заключенных внутри while select.
Спасибо.

[user_ax]

А через switch?

[Xardas]

Цитата:

Сообщение от user_ax

А через switch?

Не вижу принципиальной разницы между switch и if для тестирования значения логической переменной (принимающей всего 2 значения) за исключением того, что в switch придется писать еще case и break.

Вся проблема в том, что запросы идентичны за исключением exists и notexists.

Возможно, это реализуемо с помощью макроса?

[Evgeniy2020]

создавайте выборку программно через Query, QueryBuildDatasource
код будет более компактный

[raz]

Если query не нравится, то вариант

if (flag)
  select tableName ...
else
  select tableName ...

while tableName 
{

  next tableName;
}

вполне нормальный.

[Xardas]

для Evgeniy2020:
На данный момент в коде множество запросов, и они все разные. Их объединяет только наличие exists join ко второй таблице. Придется делать на каждый запрос свой Query.

для raz:
Да, так я избегу переписывания операторов, но запросы все равно придется дублировать.

[raz]

Цитата:

Сообщение от Xardas

Запросы разные. Их объединяет только наличие exists join. Придется делать на каждый запрос свой Query.

Зачем. Один запрос и по условию ставите разный joinMode.

[kair84]

Можно использовать макроподстановки
Важно помнить что макроподстановка выполняется в момент компиляции, а не в момент исполнения !

#localmacro.select
#define.Arg(%1)
    Select tableName
        where ...
    #if.arg('exists') exists #endIF
    #if.arg('notexists') notexists #endIF
    join joinTableName
        where ...
#endmacro

static void Job(Args _args)
{       

    if (flag)
        #select('exists');
    else
        #select('notexists');

    while (tableName)
    {
    
        next tableName;
    }
}

Если один и тот же запрос используется разных местах, можно оформить "глобальный" макрос в дереве AOT,
Нпример: \Macros\InventDimJoin

[S.Kuskov]

Когда речь заходит об оптимизации не самого кода, а процесса его написания, на первый план выходят такие критерии как наглядность, модифицируемость, маштабируемость.
Единственное достоинство оператора select - нагладность, при использовании макросов пропадает. Уж лучше Query.

[belugin]

Макрос можно покороче:

#localmacro.select
    Select tableName
        where ...
    %1
    join joinTableName
        where ...
#endmacro

static void Job(Args _args)
{       

    if (flag)
        #select(exists);
    else
        #select(notexists);

    while (tableName)
    {
    
        next tableName;
    }
}

[twilight]

Еще как вариант можно join из запросов вообще убрать. А есть ли запись в связанной таблице проверять отдельно.

[kair84]

S.Kuskov - согласен не наглядно, сам обычно использую в таких случаях Query, предложил как вариант, т.к. топикстартер отверг все предыдущие варианты. а вот с точки зрения модифицируемости - вполне.

[Xardas]

Цитата:

Сообщение от kair84

Важно помнить что макроподстановка выполняется в момент компиляции, а не в момент исполнения !

Вот это и настораживает.
Получается, что макросы в принципе нединамические. Как бы макрос не был написан, в конкретном месте основной программы все равно будет либо exists, либо notexists.

Цитата:

Сообщение от twilight

Еще как вариант можно join из запросов вообще убрать. А есть ли запись в связанной таблице проверять отдельно.

Это вообще не вариант. Представляете, как упадет производительность данного кода?

Похоже, придется использовать вариант

if (flag)
  select...
else
  select...

Что же, спасибо всем за уделенное время.

[dech]

Цитата:

Сообщение от Xardas

для Evgeniy2020:
На данный момент в коде множество запросов, и они все разные. Их объединяет только наличие exists join ко второй таблице. Придется делать на каждый запрос свой Query.

для raz:
Да, так я избегу переписывания операторов, но запросы все равно придется дублировать.

Используйте QueryBuildDataSource и разбейте на методы. Если все грамотно сделать, дублирования кода не будет. Все будут сыты и довольны.

[kair84]

2 Xardas
в данном случае макроподстановка - это способ уменьшить количество кода

PHP код:

if (flag)
  select...
else
  select... 


а в зависимости от "размера" оператора select, возможно и нагляднее будет, сразу будет видно что отличие только в способе связывания

[Владимир Максимов]

Цитата:

Сообщение от twilight

Еще как вариант можно join из запросов вообще убрать. А есть ли запись в связанной таблице проверять отдельно.

Цитата:

Сообщение от Xardas

Это вообще не вариант. Представляете, как упадет производительность данного кода?

Далеко не факт. Это надо проверять экспериментально. Как раз тот случай, когда "теоретические" рассуждения не могут дать однозначный ответ. Надо проверять.

Практика показывает, что зачастую запросы с Exists или not Exists могут вызывать просто дичайшие тормоза (даже по сравнению с вложенными циклами) и приходится сильно мудрить, чтобы этого избежать.

Кстати, ведь по описанному Вами условию, Вы имеет "зеркальные" выборки. Это значит, что если Exists будет выполняться быстро, то not Exists неизбежно будет выполняться медленно. Или наоборот. И далеко не факт, что перенесение проверки внутрь цикла существенно повлияет на среднее время выполнения. Повторюсь, это проверить надо.

А "в общем случае" рассуждения на подобную тему мало полезны. Именно в силу того, что неизвестны детали задачи. Вполне возможно, что задачу можно решить и без использования Exists просто модифицировав запрос. Однако без знания конкретной постановки задачи заранее сказать нельзя можно это сделать или нет.

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

Кстати, ведь по описанному Вами условию, Вы имеет "зеркальные" выборки. Это значит, что если Exists будет выполняться быстро, то not Exists неизбежно будет выполняться медленно. Или наоборот.

Необязательно. Например, на форму подтягиваются только отображаемые записи в грид (плюс-минус еще несколько). И будет там exists или notexists - это уже не столь важно.

Проверял на АХ 2009, когда делал грид из InventTable с 70 тыс записями. Я добавлял туда к каждой записи галку "Маркировать" (edit-метод) и добавлял в контекстное меню по правой кнопке мыши пункт "Фильтр по выделенному" по этому edit-методу. Маркироваться могли абсолютно непредсказуемые записи и в больших количествах (>1000). Соответственно - для целей фильтрации в коде в одном случае - делался exists join, в другом - not exists. Работало одинаково.

А вот то, что разбивать не стоит - факт.
Опять-таки - пример. Запустите расчет сводного плана, имея большой справочник номенклатур. Если у Вас заполнены Настройки-Покрытие номенклатуры (ReqItemTable) - то расчет отработает. Если не заполнены - то не отработает. Обратите внимание - сколько времени отрабатывает "вхолостую" расчет, просто бегая в цикле по большому справочнику номенклатуры. Хотя простейшая оптимизация вида InventTable exists join ReqItemTable могла бы делать пересчет сводного плана мгновенным, при условии, что записей в ReqItemTable много меньше, чем в InventTable

[Владимир Максимов]

Цитата:

Сообщение от sukhanchik

А вот то, что разбивать не стоит - факт.

Нет. Не факт Я же говорю, когда речь идет об exist, то все надо проверять экспериментально. Практический результат (скорость выполнения) - слабо предсказуем "теоретическими" рассуждениями.

Тут "фишка" в том, что физически на MS SQL сервере выполняется не "голый" запрос, а запрос "обернутый" в курсор (DECLARE CURSOR ... FOR). Как следствие, планы выполнения "голого" запроса и курсора могут существенно отличаться. Однако здесь ключевое слово "могут". Могут отличаться, а могут и не отличаться. Зависит от кучи условий, не всеми из которых можно управлять.

Лично я "напоролся" на подобные различия именно в запросах с Exists. В запросах, где exists отсутствует я подобных различий не наблюдал. Отсюда и повышенная настороженность к подобным запросам.

[mazzy]

Цитата:

Сообщение от kair84

Можно использовать макроподстановки

Не надо использовать макросы (если это не константы)
причины уже назыавали.

[gl00mie]

Цитата:

Сообщение от Xardas

Имеется класс с большим количеством запросов вида

select tbl1
exists join tbl2
where tbl2.field1 == tbl1.field1

Сейчас возникла необходимость модифицировать данный код: Если значение некоторой логической переменной истина, то соединение таблиц должно производиться с помощью exists join. Если значение этой же логической переменной ложь, то соединение должно производиться с помощью notexists join. Можно ли произвести данную модификацию?

Есть время разбрасывать камни и время их собирать. Кто-то поленился нормально написать код, избавиться от дублирования, вынести принятие однотипных решений в одно место, а теперь придется либо наплодить кучу copy-paste'а, либо засучить рукава и провести серьезный рефакторинг кода.

Цитата:

Сообщение от Xardas

Похоже, придется использовать вариант

if (flag)
  select...
else
  select...

Что же, спасибо всем за уделенное время.

Не стоит так делать. Тут уже писали, наиболее нормальный вариант, позволяющий менять тип join'а во время выполнения, - это переписать код на Query'ках. Решать проблему copy-paste'ом - все равно, что заметать сор под половик в надежде, что убирать его придется кому-то другому; это непрофессионально, в конце концов