Как оптимально написать T-SQL запрос для выборки настройки Table/Group/All (например, счет ГК из профиля разноски)

[fed]

В общем - по моим наблюдениям, SQL вообще очень неважно оптимизирует запросы с OR в условиях джойна.
Я бы пошел по такому пути:
1. Создал бы вспомогательную таблицу с полями клиент, группа, профиль и счет ГК.
2. Заполнил бы эту таблицу декартовым произведением профилей и клиентов
3. Потом прогнал бы по этой таблице три update. Первый update джойнит вспомогательную таблицу с custLedger по условию совпадения профиля и клиента. Второй update обновляет только строки с пустым счетом ГК и по условию совпадения профиля и группы клиентов.Третий update действует аналогично но работает уже только по профилю разноски.
4. Каждый из запросов в пункте 3 надо проанализировать и построить подходящие индексы (поскольку каждый из джойнов только по AND, проблем быть не должно).
5. Потом джойнишь custTrans со вспомогательной таблицей.

P.S. Пожалуй что декартово произведение из пункта 2, можно заменить просто сбором уникальных комбинаций клиента и профиля из custTrans

[mazzy]

Цитата:

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

А совпадения РК - ГК пользователи не ожидают ?

конечно ожидают. и конечно не получают. но это отдельная тема.
вернемся к T-SQL запросу для выборки настройки Table/Group/Al.

Цитата:

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

В общем - по моим наблюдениям, SQL вообще очень неважно оптимизирует запросы с OR в условиях джойна.

а при чем здесь or?
проблема:

Цитата:

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

Основная проблема - в настроечной таблице для одной проводки может быть несколько разных подходящих настроек для одной исходной мастер-записи.

если вернуться к примеру, то для одного клиента в базе может быть ОДНОВРЕМЕННО несколько настроек: для него самого, для его группы и для всех.
некоторые (или все) настройки могут отсутствовать.

Цитата:

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

1. Создал бы вспомогательную таблицу с полями клиент, групп, профиль и счет ГК.
2. Заполнил бы эту таблицу декартовым произведением профилей и клиентов
3. Потом прогнал бы по этой таблице три update.

дык, код получается нереентерабельным.
возможно, что этот запрос выполняется одновременно несколькими внешними программами с разными критериями выборки. будешь эмулировать временную таблицу?

если будешь эмулировать, то нафига она вообще нужна, давай сформулируем как сделать select, который реализует твой алгоритм.

[mazzy]

Цитата:

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

Я бы пошел по такому пути:

кстати, ты просто переформулировал мой второй пример наивной реализации с isnull )))

with trans as (
SELECT
    isnull(accTable.SUMACCOUNT, isnull(accGroup.SumAccount, accAll.SumAccount)) as pSumAccount,
    tr.*
from custtrans as tr
join custtable as tab on (tab.DATAAREAID = tr.DATAAREAID and tab.accountnum = tr.accountnum)
left join CUSTLEDGERACCOUNTS as accTable
    on (accTable.DATAAREAID = tr.DATAAREAID
    and accTable.POSTINGPROFILE = tr.POSTINGPROFILE
    and accTable.AccountCode = 0 and accTable.NUM = tab.ACCOUNTNUM)
left join CUSTLEDGERACCOUNTS as accGroup 
    on (accTable.DATAAREAID = tr.DATAAREAID
    and accGroup.POSTINGPROFILE = tr.POSTINGPROFILE
    and accGroup.AccountCode = 1 and accGroup.NUM = tab.CUSTGROUP)
left join CUSTLEDGERACCOUNTS as accAll
    on (accAll.DATAAREAID = tr.DATAAREAID
    and accAll.POSTINGPROFILE = tr.POSTINGPROFILE
    and accAll.AccountCode = 2)
)
select *
from trans
--where trans.DATAAREAID in ('dmr')

[Alexius]

Цитата:

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

Цитата:

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

Я бы пошел по такому пути:

кстати, ты просто переформулировал мой второй пример наивной реализации с isnull )))

Не-е-е, это другой подход и идея очень интересная:
1. Создаем временную таблицу КодКлиента (группа клиента не нужна), Профиль, СчетГК
2. Заполняем всеми пересечениями КодКлиента, Профиль из проводок (желателен такой индекс)
3. Делаем обновление в ней СчетаГК из настроек 3-мя запросами: сначала Все, потом Группа и наконец Таблица
4. Строим запрос по проводкам с привязкой временной таблицы по INNER JOIN
5. Индексы по вкусу