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

[gl00mie]

Цитата:

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

Задача:
внешняя система читает проводки по клиентам. Причем внешняя система для каждой проводки ожидает получить в выборке счет ГК из профиля разноски. Как оптимально написать T-SQL запрос для такой выборки?
Основная проблема - в настроечной таблице для одной проводки может быть несколько разных подходящих настроек для одной исходной мастер-записи.

Какая-то нетипичная задача, как мне кажется, и потому она требует нетипичного (с т.з. Аксапты) подхода к решению.

Цитата:

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

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

Тут, по-моему, может быть несколько вариантов:

1. • понятная пользователю настроечная таблица
   • не требует дополнительных затрат для ее поддержки
   • не очень удобно работать с настройками из TSQL;
2. • понятная пользователю настроечная таблица
   • дополнительные затраты для поддержки SQL-friendly представления данных
   • удобно работать с настройками из TSQL;
3. • непонятная пользователю настроечная таблица с SQL-friendly представленем данных
   • не требует дополнительных затрат для ее поддержки
   • удобно работать с настройками из TSQL;

В стандартной Аксапте выбрали 1-й вариант, потому что совсем нечасто стоит задача обработать большую выборку данных и на лету подобрать для каждой записи выборки некий параметр из настроечной таблицы со связями Table/Group/All. Намного чаще обработка идет по одной записи, и по ее полям нужно быстро получить настроечный параметр. При таком раскладе таблица должна быть как можно более понятна для пользователя, который делает настройки, максимум, что от нее требуется, - это обеспечивать нужную сортировку записей. Всё остальное решается кэшированием таблиц в ядре Аксапты и кэшированием результатов выборки в каком-нить SysGlobalobjectCache, как часто делается в 12-ке.
Но возьмем для примера иерархию категорий из AX 2012. С одной стороны, есть понятная пользователю настроечная таблица, хранящая узлы иерархии (категории), а с другой, для той или иной категории есть потребность быстро определять в запросах связанные подкатегории выше по иерархии, на которые могут ссылаться другие настройки, скажем, те же скидки за комплект и т.п. Тут уже разработчики стандарта пошли по второму пути из приведенных выше и реализовали таблицу RetailCategoryContainmentLookup, содержащую SQL-friendly представление иерархии категорий.
Так вот, мне кажется, в следующем сценарии:

• внешняя система читает проводки по клиентам
• для каждой проводки ожидает получить в выборке счет ГК из профиля разноски
• в настроечной таблице для одной проводки может быть несколько разных подходящих записей
• записи настроечной таблицы должны выбираться с учетом определенного приоритета

имеет смысл реализовать 2-й вариант хранения настроек и сделать их SQL-friendly представление, которое уже использовать при чтении проводок. Такое представление, в зависимости от дополнительных условий и ограничений, может как храниться и поддерживаться на постоянной основе, так и строиться ad-hoc перед началом чтения данных внешней системой. Если же затраты на поддержку такого SQL-friendly представления настроек кажутся чрезмерными, то, вероятно, и "трудозатраты" СУБД при выполнении подзапросов не должны особо смущать.