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

[mazzy]

Цитата:

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

у меня такой запрос на demo выполняется мгновенно

))))))

Анекдот:
принимают секретаршу на работу. Спрашивают:
- с какой скоростью печатаете?
- 1000 знаков в минуту
- вы приняты!!!!!
- (думает про себя) такая фигня получается.

и сам в эту сторону думал, и предполагал что и другие в эту сторону пойдут...

Цитата:

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

Аксапта всегда в первую очередь использует настройку для Table, если таковая есть. Если настройки для Table нет, то Аксапта ищет настройку для Group. Если и таковой нет, то Аксапта ищет настройку для All. Вполне возможно, что настройка может отсутствовать.
....
Основная проблема - в настроечной таблице для одной проводки может быть несколько разных подходящих настроек для одной исходной мастер-записи.

нет, нельзя делать просто union.
для одного профиля может быть несколько подходящих настроек - и для конкретного значения Table, и для группы и для всех. Аксапта в этом случае выбирает ОДНУ настройку. union возвратит все подходящие. А настройка Все используется очень часто.

))))))

[Alexius]

Цитата:

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

нет, нельзя делать просто union.
для одного профиля может быть несколько подходящих настроек - и для конкретного значения Table, и для группы и для всех. Аксапта в этом случае выбирает ОДНУ настройку. union возвратит все подходящие. А настройка Все используется очень часто.

Решается с помощью обертки, но какая получится скорость - вопрос.

SELECT ACCOUNTNUM, ACCOUNTCODE, POSTINGPROFILE, DATAAREAID, RECID
  , CASE WHEN MAX(Value0) <> '' THEN MAX(Value0) ELSE CASE WHEN MAX(Value1) <> '' THEN MAX(Value1) ELSE MAX(Value2) END END Value
FROM 
(
  select ct.ACCOUNTNUM, cla.ACCOUNTCODE, cla.POSTINGPROFILE, dim.DISPLAYVALUE Value0, '' Value1, '' Value2, cla.DATAAREAID, ct.RECID from CUSTTABLE as ct
  join CUSTLEDGERACCOUNTS as cla on
	  ct.ACCOUNTNUM = cla.NUM and
	  ct.DATAAREAID = cla.DATAAREAID and
	  cla.ACCOUNTCODE = 0
  join DIMENSIONATTRIBUTEVALUECOMBINATION as dim on
	  cla.SUMMARYLEDGERDIMENSION = dim.RECID
	  where 
		  ct.DATAAREAID = 'usmf'
  union
  select ct1.ACCOUNTNUM, cla1.ACCOUNTCODE, cla1.POSTINGPROFILE, '', dim1.DISPLAYVALUE, '', cla1.DATAAREAID, ct1.RECID from CUSTTABLE as ct1
  join CUSTLEDGERACCOUNTS as cla1 on
	  ct1.CUSTGROUP = cla1.NUM and
	  ct1.DATAAREAID = cla1.DATAAREAID and
	  cla1.ACCOUNTCODE = 1
  join DIMENSIONATTRIBUTEVALUECOMBINATION as dim1 on
	  cla1.SUMMARYLEDGERDIMENSION = dim1.RECID
		  where 
		  ct1.DATAAREAID = 'usmf'
  union
  select ct2.ACCOUNTNUM, cla2.ACCOUNTCODE, cla2.POSTINGPROFILE, '', '', dim2.DISPLAYVALUE, cla2.DATAAREAID, ct2.RECID from CUSTTABLE as ct2
  join CUSTLEDGERACCOUNTS as cla2 on
	  ct2.DATAAREAID = cla2.DATAAREAID and
	  cla2.ACCOUNTCODE = 2
  join DIMENSIONATTRIBUTEVALUECOMBINATION as dim2 on
	  cla2.SUMMARYLEDGERDIMENSION = dim2.RECID
	  where 
		  ct2.DATAAREAID = 'usmf'
) T
GROUP BY ACCOUNTNUM, ACCOUNTCODE, POSTINGPROFILE, DATAAREAID, RECID

[KiselevSA]

Цитата:

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

Решается с помощью обертки, но какая получится скорость - вопрос.

Обертку можно не делать, достаточно отобрать запись с минимальным значением AccountCode: именно эта запись работает при разноске.
Но есть одна засада, о которой ТС не задумался: а что будет, если настройки профиля меняли после того, как пошли проводки. Насколько я помню, полей Valid... в настроечных таблицах нет.

[Raven Melancholic]

У нас уже несколько лет из портала получают такие настройки способом, который в теме назван "наивным". То есть, получение всех вариантов с left outer join.
Не могу подвести какую-то теоретическую базу под такой выбор - просто когда помогали WEB программистам с построением запроса, получилось, что в экспериментах это был наиболее быстрый вариант.
Только у нас не отбирается потом одно единственное значение, а выводятся все три в разных полях. Возможно, что именно для счета ГК или каких-то других настроек, у которых результат может быть только один, так и нужно отбирать. Но у нас такие запросы, в основном, используются для получения цен-скидок. А там, как всем известно, благодаря флагу "Искать далее" для цен и скидок можно выбирать не просто строку, наиболее точно подходящую под составляющие части настройки (номенклатура более важна, чем группа номенклатур, группа клиентов более важна, чем все клиенты и т.п.), а суммировать скидки и выбирать наиболее низкие цены. Поэтому запрос возвращает все три варианта в разных колонках, а уже бизнес-логика на PHP определяет нужный.