Цитата:
Сообщение от
mazzy
Задача:
внешняя система читает проводки по клиентам. Причем внешняя система для каждой проводки ожидает получить в выборке счет ГК из профиля разноски. Как оптимально написать T-SQL запрос для такой выборки?
Основная проблема - в настроечной таблице для одной проводки может быть несколько разных подходящих настроек для одной исходной мастер-записи.
Какая-то нетипичная задача, как мне кажется, и потому она требует нетипичного (с т.з. Аксапты) подхода к решению.
Цитата:
Сообщение от
mazzy
как, на ваш взгляд должны быть устроены подобные настроечные таблицы, чтобы и без Аксаптовского кэширования можно было бы удобно работать с такими настроечными таблицами на уровне SQL?
Тут, по-моему, может быть несколько вариантов:
- понятная пользователю настроечная таблица
- не требует дополнительных затрат для ее поддержки
- не очень удобно работать с настройками из TSQL;
- понятная пользователю настроечная таблица
- дополнительные затраты для поддержки SQL-friendly представления данных
- удобно работать с настройками из TSQL;
- непонятная пользователю настроечная таблица с SQL-friendly представленем данных
- не требует дополнительных затрат для ее поддержки
- удобно работать с настройками из TSQL;
В стандартной Аксапте выбрали 1-й вариант, потому что совсем нечасто стоит задача обработать большую выборку данных и на лету подобрать для каждой записи выборки некий параметр из настроечной таблицы со связями Table/Group/All. Намного чаще обработка идет по одной записи, и по ее полям нужно быстро получить настроечный параметр. При таком раскладе таблица должна быть как можно более понятна для пользователя, который делает настройки, максимум, что от нее требуется, - это обеспечивать нужную сортировку записей. Всё остальное решается кэшированием таблиц в ядре Аксапты и кэшированием результатов выборки в каком-нить SysGlobalobjectCache, как часто делается в 12-ке.
Но возьмем для примера иерархию категорий из AX 2012. С одной стороны, есть понятная пользователю настроечная таблица, хранящая узлы иерархии (категории), а с другой, для той или иной категории есть потребность быстро определять в запросах связанные подкатегории выше по иерархии, на которые могут ссылаться другие настройки, скажем, те же скидки за комплект и т.п. Тут уже разработчики стандарта пошли по второму пути из приведенных выше и реализовали таблицу RetailCategoryContainmentLookup, содержащую SQL-friendly представление иерархии категорий.
Так вот, мне кажется, в следующем сценарии:
- внешняя система читает проводки по клиентам
- для каждой проводки ожидает получить в выборке счет ГК из профиля разноски
- в настроечной таблице для одной проводки может быть несколько разных подходящих записей
- записи настроечной таблицы должны выбираться с учетом определенного приоритета
имеет смысл реализовать 2-й вариант хранения настроек и сделать их SQL-friendly представление, которое уже использовать при чтении проводок. Такое представление, в зависимости от дополнительных условий и ограничений, может как храниться и поддерживаться на постоянной основе, так и строиться ad-hoc перед началом чтения данных внешней системой. Если же затраты на поддержку такого SQL-friendly представления настроек кажутся чрезмерными, то, вероятно, и "трудозатраты" СУБД при выполнении подзапросов не должны особо смущать.