Цитата:
Сообщение от
NetBus
Если все время писать while select и бороду условий - то это не есть гуд, хочется описать один раз и потом только пользоваться.
1. RecordRefrenceList_RU - заполняем RecordReferenceList_RU делаем join к таблице - работаем с записями
2. Заполняем RecordSortedList перебираем в цикле - работаем с записями
3. Временная таблица - надеюсь понятно
4. написать цикл и использовать метод find() на простых таблицах, у которых установлено свойство CashedLookup=EntireTable или Found
дело в том, что ядро аксапты ооочень много кэширует.
изначально таблицы в Аксапте очень четко делились на параметры/справочники/документы/проводки
параметры содержат только одну запись для каждой компании
справочники редко редактируются, но часто читаются
документы - в основном произвольный доступ в ручном режиме, очень редки bulk операции
проводки - только добавляются, никогда не удаляются и в очень исключительных ситуациях редактируются (корреспонденция, к сожалению, - антипаттерн)
это со стороны ядра Аксапты.
со стороны SQL есть кэширование планов запросов/статистики и прочее техническое кэширование.
в SQL
в многопользовательском режиме лучше отправлять не уникальные разные запросы с кучей join, а поток стандартизированных сравнительно простых запросов.
таким образом - уникальные select с бородой запросов - это плохой подход в большинстве случаев. Да, есть случаи когда один-два-три сложных запросов лучше, чем куча простых запросов. Но в большинстве своем лучше стремиться к стандартизированным запросам, полученные результаты которых может быть дополнительно обрабатываются уже в классе.
Исходя из этого в Аксапте и сложился стиль - бизнес-логика почти не занимается такими низкоуровенвыми вещами как запросы.
бизнес-логика должна вызывать классы, которые в свою очередь будут делать относительно простые и стандартизированные запросы к базе.
да, люди которые привыкли напрямую работать с SQL, часто морщатся от такого подхода.
да, в аксапте иногда очень не хватает union, having и вложенных запросов. да, иногда приходится юзать ResultSet
см.
https://github.com/mazzy-ax/SysResultSet
а также комментарии в
https://github.com/mazzy-ax/SysResul...sultSet_AX.xpo
но в большинстве случаев лучше и эффективнее пользоваться логическим разбиением на слои:
1. бизнес-логика обращается к специализированным классам
2. специализированные классы делают относительно простые запросы и/или обращаются к другим классам.
в большинстве случаев не пытайтесь сделать монстр-запрос. лучше обычные циклы, которые вызывают методы классов.
во-первых, монстр-запрос это преждевременная оптимизация )
во-вторых, во многих случаях
в многопользовательской системе монстр-запрос будет работать хуже и будет дороже в обслуживании.
=========================
и уж точно не занимайтесь RecordSortedList и RecordRefrenceList_RU, если у вас не стоит явная задача именно оптимизации производительности данного конкретного участка.
=========================
временные таблицы можно использовать когда вы точно знаете, что вам нужен промежуточный результат, И объем этого результата в разы, на порядки меньше, чем объем исходных данных.
вопрос временных таблиц оооочень сильно зависит от версии системы.
не закладывайтесь на временные таблицы только из соображений производительности. скорее всего, вы ничего не выиграете. особенно для "произвольных запросов".