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

[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

[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;
    }
}

[Xardas]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

Цитата:

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

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

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

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

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

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

[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'ом - все равно, что заметать сор под половик в надежде, что убирать его придется кому-то другому; это непрофессионально, в конце концов

[mazzy]

Цитата:

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

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

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

[dech]

Цитата:

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

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

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

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

[kair84]

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

PHP код:

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


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

[S.Kuskov]

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

[twilight]

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

[kair84]

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

[Xardas]

Зря вы иронизируете. Может, вы не поняли, но запросы в коде разные. Специально для вас подчеркиваю это слово.
Нужен пример? Да запросто.
Первый запрос:

while select tbl1
      group by EmplId, Organization
      where tbl1.PostDate >= startPeriod &&
            tbl1.PostDate <= endPeriod &&
            tbl1.Organization like organization + "*"
        exists join tbl2
        where tbl2.Key  == tbl1.Key &&
              tbl2.Sham == NoYes::No

Второй запрос:

select sum(Amount)
from tbl1
group by EmplId
where tbl1.PostDate     <  startPeriod &&
      tbl1.EmplId       == temp.EmplId &&
      tbl1.Organization == temp.Organization
  exists join tbl2
  where tbl2.Key  == tbl1.Key &&
        tbl2.Sham == NoYes::No;

И таких запросов несколько.
Ну и как тут обойтись одной кверей? Для каждого запроса менять ее?

[lev]

Цитата:

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

Ну и как тут обойтись одной кверей? Для каждого запроса менять ее?

Query query = new Query();
QueryBuildDataSource qbds, qbdsJoin;

boolean groupByEmplId, groupByOrg;
boolean sumAmountField;
boolean selectForEmplId;
boolean needJoin;
;

qbds = query.addDataSource(tableNum(tbl1));
qbds.OrderMode(OrderMode::GroupBy);

if (needJoin)
{
   qbdsJoin =  qbds.addDataSource(tableNum(tbl2));
   qbdsJoin.relations(true);
}

if (groupByEmplId)
      qbds.addSortField(fieldNum(tbl1, EmplId));

if (groupByOrg)
      qbds.addSortField(fieldNum(tbl1, Organization));

if (selectForEmplId)
   qbds.addRange(fieldNum(tbl1, EmplId)).value(queryValue(temp.EmplId));

if (sumAmountField)
   qbds.addSelectionField(fieldNum(tbl1, Amoun), SelectionField::Sum);

// и т.д. и т.п ....