AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.10.2016, 16:20   #1  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Выбор записей из таблицы произвольным запросом
Добрый день!
Есть задача выбрать из таблицы записи очень сложным запросом с ветвистой логикой, а по выбранным записям делать всевозможные преобразования. Хочется инкапсулировать процедуру поиска строк и потом использовать во всевозможных преобразованиях. Выбираю между (решения по убыванию приоритета предпочитаемости):

1. RecordRefrenceList_RU
Минусы - номерные серии, вставка очистка, нельзя использовать в постоянно используемом функционале.

2. RecordSortedList
Минусы - дополнительная логика на update и delete строк

3. Временная таблица
Минусы - большие временные затраты.

Вопрос - может пропустил что? Другие доводы?

Axapta 2009
За это сообщение автора поблагодарили: Ace of Database (5), S.Kuskov (5).
Старый 13.10.2016, 16:29   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
У вас задача как-то нечетко описана.
Непонятно что же именно нужно и как один пункт может заменить другой.
Например, как RecordSortedList заменит RecordRefrenceList_RU ?

Опишите тогда вашу задачу более детально.
Старый 13.10.2016, 16:35   #3  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Есть таблица, из нее нужно выбрать по некоторому алгоритму строки.
Если все время писать while select и бороду условий - то это не есть гуд, хочется описать один раз и потом только пользоваться.
1. RecordRefrenceList_RU - заполняем RecordReferenceList_RU делаем join к таблице - работаем с записями
2. Заполняем RecordSortedList перебираем в цикле - работаем с записями
3. Временная таблица - надеюсь понятно
Старый 13.10.2016, 16:55   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от NetBus Посмотреть сообщение
1. RecordRefrenceList_RU
Минусы - номерные серии, вставка очистка, нельзя использовать в постоянно используемом функционале.
А Вы не работайте с классом (если не хотите его менять), а работайте напрямую с таблицей. Номерные серии? А зачем? Нельзя придумать иную уникальную комбинацию? (например, код сессии пользователя, код класса, дата/время и т.д.).
Почему нельзя использовать в постоянно используемом функционале?
Там неправильно хранить записи, но добавить их туда с перспективой удаления - почему бы и нет.
Если все-таки хочется хранить ссылки, то всегда можно создать свою таблицу, аналогичную RecordReferenceList_RU (точнее пару таблиц - шапку и строки сессии выборки данных). Работает все быстро, памяти не кушает - все удобно.
Впоследствии хорошо фильтровать данные, а также выводить отфильтрованные данные в привычной форме (например, можно т.о. собрать список номенклатур и открыть стандартную форму номенклатур, отфильтрованную по джойну с вашей таблицей ссылок. Или т.о. отобрать складские проводки).

Цитата:
Сообщение от NetBus Посмотреть сообщение
2. RecordSortedList
Минусы - дополнительная логика на update и delete строк
А также - расход памяти и невозможность впоследствии увидеть исторические результаты выборок.

Цитата:
Сообщение от NetBus Посмотреть сообщение
3. Временная таблица
Минусы - большие временные затраты.
А также - расход места на диске, который скорее всего не предназначен для хранения данных БД и увеличение времени выборки за счет отсутствия каких-либо индексов.

В общем - используйте RecordReferenceList_RU и не мучайтесь
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: NetBus (2).
Старый 13.10.2016, 17:08   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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, если у вас не стоит явная задача именно оптимизации производительности данного конкретного участка.

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

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

Последний раз редактировалось mazzy; 13.10.2016 в 17:44.
За это сообщение автора поблагодарили: NetBus (2), alex55 (1), dech (3).
Старый 13.10.2016, 17:15   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
А Вы не работайте с классом (если не хотите его менять), а работайте напрямую с таблицей.
...
В общем - используйте RecordReferenceList_RU и не мучайтесь
Оп! Категорически не согласен!

вопрос опять о "произвольных запросах" и о сферических конях в вакууме типа "выбрать из таблицы". (из одной, карл!)
для Аксапты, для прикладной программы уровня предприятия "произвольные запросы" - предельно редкое явление.
встречающееся на уровне программирования ядра и функционала администрирования.

запрос к ОДНОЙ таблице - встречается как правило только на этапе отладки или как запрос параметров (но для параметров точно нужно использовать find()).
запрос к одной таблице, которая не является параметрами - редкое явление.
а в версии 2012 и выше с искусственными ключами - исключительное явление.

для Аксапты характерно очень прикладное программирование.
для прикладного программирования "работать напрямую с таблицей" - антипаттерн.
в прикладной программе типа аксапты обычно работают с набором взаимосвязанных таблиц!!!!

работать с набором взаимосвязанных таблиц напрямую? нонсенс!

Последний раз редактировалось mazzy; 13.10.2016 в 17:30.
Старый 13.10.2016, 17:34   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от mazzy Посмотреть сообщение
работать с набором взаимосвязанных таблиц напрямую? нонсенс!
особенно, если в наборе есть таблицы, для которых включен Valid Time State
https://msdn.microsoft.com/en-us/library/gg861781.aspx
Старый 13.10.2016, 18:06   #8  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Всем спасибо за участие!
Познавательно, вспомнил еще способ
5. macros а ля InventDimJoin как в складском модуле.
Выбирай на любой вкус... ушел думать
Старый 13.10.2016, 18:45   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от NetBus Посмотреть сообщение
Всем спасибо за участие!
Познавательно, вспомнил еще способ
5. macros а ля InventDimJoin как в складском модуле.
Выбирай на любой вкус... ушел думать
макрос - это всего лишь синтаксический сахарн для запроса-монстра с бородой )
Старый 13.10.2016, 18:53   #10  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
макрос - это всего лишь синтаксический сахарн для запроса-монстра с бородой )
Да, полностью согласен, привёл до кучи и полноты картины.
Старый 13.10.2016, 20:25   #11  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от NetBus Посмотреть сообщение
Есть задача выбрать из таблицы записи очень сложным запросом с ветвистой логикой, а по выбранным записям делать всевозможные преобразования. Хочется инкапсулировать процедуру поиска строк и потом использовать во всевозможных преобразованиях.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Оп! Категорически не согласен!
вопрос опять о "произвольных запросах" и о сферических конях в вакууме типа "выбрать из таблицы". (из одной, карл!)
для Аксапты, для прикладной программы уровня предприятия "произвольные запросы" - предельно редкое явление.
встречающееся на уровне программирования ядра и функционала администрирования.

для Аксапты характерно очень прикладное программирование.
для прикладного программирования "работать напрямую с таблицей" - антипаттерн.
в прикладной программе типа аксапты обычно работают с набором взаимосвязанных таблиц!!!!

работать с набором взаимосвязанных таблиц напрямую? нонсенс!
Цитата:
Сообщение от mazzy Посмотреть сообщение
особенно, если в наборе есть таблицы, для которых включен Valid Time State
https://msdn.microsoft.com/en-us/library/gg861781.aspx
Ну давайте тогда уж разберем кто чего понял.

Итак, задача 1
Цитата:
Сообщение от NetBus Посмотреть сообщение
Есть задача выбрать из таблицы записи очень сложным запросом
Из этой задачи следует, что нужно выбрать из одной (да-да, из одной!) таблицы.
В этом случае класс RecordReferenceList_RU очень хорошо помогает. Про прикладное программирование - хорошее замечание. Но... вопрос не ставился как "работать ли напрямую с таблицей или использовать промежуточный класс?". Автор как раз хотел использовать класс, а я ему советовал так не делать. Тут я был неправ, но хочу сказать, что без модификаций класса RecordReferenceList_RU его использовать будет не очень удобно - тогда действительно придется связываться с номерными сериями. Резюме: класс нужен, но не совсем такой, какой есть в штатной поставке.

По поводу набора таблиц. Начиная с АХ 2012 и выше - надо будет помнить, что "простейший" справочник типа клиентов / номенклатуры и т.д. состоит не из одной таблицы, а из набора таблиц, связанных друг с другом и в данном случае ссылкой на одну запись в одной таблице можно не обойтись. Однако, автор указывает, что версия как раз АХ 2009, в которой еще многие справочники состоят из одной таблицы и поэтому решение предлагается именно для этой версии. Для версии АХ 2012 оно (решение) было бы другим. Соответственно таблиц, для которых включен Valid Time State в АХ 2009 нет и об этом в АХ 2009 не надо заморачиваться.

Теперь задача 2
Цитата:
Сообщение от NetBus Посмотреть сообщение
а по выбранным записям делать всевозможные преобразования. Хочется инкапсулировать процедуру поиска строк и потом использовать во всевозможных преобразованиях.
А вот тут уже RecordReferenceList_RU помощь в инкапсуляции не даст. Потому что фраза "всевозможные преобразования" предполагает разные преобразования разных записей. А это значит, что их надо как-то уже снова выбирать и анализировать. И тогда надо действительно писать методы find*, выносить сами select-ы на таблицы и / или в "приближенные к ним" классы.

Т.о. если Вам надо:
- выбрать произвольным образом записи из ОДНОЙ таблицы для ИСКЛЮЧИТЕЛЬНО целей дальнейшей фильтрации и / или отображения по ним - то можно использовать RecordReferenceList_RU
- выбрать произвольным образом записи из одной или нескольких таблиц и в последующем их как-то обрабатывать "всевозможными преобразованиями", то нужно писать find-ы и делать логику в семействе классов (т.е. создавать ряд классов, занимающихся обработкой и поиском; выносить общий код в классы-родители и т.д.)
__________________
Возможно сделать все. Вопрос времени
Старый 13.10.2016, 20:56   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Т.о. если Вам надо:
- выбрать произвольным образом записи из ОДНОЙ таблицы для ИСКЛЮЧИТЕЛЬНО целей дальнейшей фильтрации и / или отображения по ним - то можно использовать RecordReferenceList_RU
- выбрать произвольным образом записи из одной или нескольких таблиц и в последующем их как-то обрабатывать "всевозможными преобразованиями", то нужно писать find-ы и делать логику в семействе классов (т.е. создавать ряд классов, занимающихся обработкой и поиском; выносить общий код в классы-родители и т.д.)
ок. с этим выводом согласен

=====================
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ну давайте тогда уж разберем кто чего понял.
Давай )))

тема: Выбор записей из таблицы произвольным запросом
Цитата:
Сообщение от NetBus Посмотреть сообщение
Есть задача выбрать из таблицы записи очень сложным запросом с ветвистой логикой
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Из этой задачи следует, что нужно выбрать из одной (да-да, из одной!) таблицы.
сложный запрос? из одной? с ветвистой логикой? ))))
да, я тоже обратил внимание на единственное число.
но подумал, что люди хотят не то, что спрашивают, и срашивают не то, что хотят. как обычно. )

но если предположить твою трактовку:
а какой запрос по какой таблице аксапты ты бы назвал подходящим под определение "сложная и ветвистая логика запроса по одной таблице"?
просто интересно.


Цитата:
Сообщение от sukhanchik Посмотреть сообщение
В этом случае класс RecordReferenceList_RU очень хорошо помогает. Про прикладное программирование - хорошее замечание. Но... вопрос не ставился как "работать ли напрямую с таблицей или использовать промежуточный класс?". Автор как раз хотел использовать класс, а я ему советовал так не делать. Тут я был неправ, но хочу сказать, что без модификаций класса RecordReferenceList_RU его использовать будет не очень удобно - тогда действительно придется связываться с номерными сериями. Резюме: класс нужен, но не совсем такой, какой есть в штатной поставке.
эмммм. у меня есть соображения по поводу этого класса и по поводу того что надо оторвать автору класса. но давай я попридержу и спрошу:
а что ты имеешь в виду? что должно быть в таком классе? и чем это будет лучше чем набор отдельных запросов в сложной и ветвистой логике?

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Однако, автор указывает, что версия как раз АХ 2009, в которой еще многие справочники состоят из одной таблицы и поэтому решение предлагается именно для этой версии.
сложная и ветвистая логика для справочника?
да, ну, брось...

я понимаю еще таблицу с проводками. в результате надо получить дебет-кредит с учетом сторно и какие-нибудь хитрые группировки. но группировки по одной таблице проводок, не заглядывая в справочники?

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

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Для версии АХ 2012 оно (решение) было бы другим. Соответственно таблиц, для которых включен Valid Time State в АХ 2009 нет и об этом в АХ 2009 не надо заморачиваться.
то, что у автора 2009 не значит, что не стоит учитывать и старшие версии.
читают то многие. а вопрос неплохой вроде.

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
А это значит, что их надо как-то уже снова выбирать и анализировать. И тогда надо действительно писать методы find*, выносить сами select-ы на таблицы и / или в "приближенные к ним" классы.
раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))
Старый 13.10.2016, 21:15   #13  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
сложный запрос? из одной? с ветвистой логикой? ))))
да, я тоже обратил внимание на единственное число.
но подумал, что люди хотят не то, что спрашивают, и срашивают не то, что хотят. как обычно. )
В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать . Нужен автор с более детальным примером .
Цитата:
Сообщение от mazzy Посмотреть сообщение
но если предположить твою трактовку:
а какой запрос по какой таблице аксапты ты бы назвал подходящим под определение "сложная и ветвистая логика запроса по одной таблице"?
просто интересно.
InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.

Цитата:
Сообщение от mazzy Посмотреть сообщение
эмммм. у меня есть соображения по поводу этого класса и по поводу того что надо оторвать автору класса. но давай я попридержу и спрошу:
а что ты имеешь в виду? что должно быть в таком классе? и чем это будет лучше чем набор отдельных запросов в сложной и ветвистой логике?
Набор отдельных запросов в сложной и ветвистой логике однозначно лучше. В классе явно не хватает возможности задавать (а не генерить) parmId. За счет этого получается использование номерных серий. А т.к. функционал в классе скромный (максимум join да flush заслуживает внимания) - то тут как бы особо и добавить нечего.

Цитата:
Сообщение от mazzy Посмотреть сообщение
сложная и ветвистая логика для справочника?
да, ну, брось...
да, я как-то незаметно стал ассоциировать "одну таблицу" со справочником. Каюсь.

Цитата:
Сообщение от mazzy Посмотреть сообщение
я понимаю еще таблицу с проводками. в результате надо получить дебет-кредит с учетом сторно и какие-нибудь хитрые группировки. но группировки по одной таблице проводок, не заглядывая в справочники?
Легко, если:
а) использовать что-то типа InventTrans, из которого еще не выкосили "лишние" поля
б) сознательно денормализовать нормализованные Микрософтом таблицы для ускорения выборок.

Цитата:
Сообщение от mazzy Посмотреть сообщение
а сложную и ветвистую логику для справочника из одной таблицы? дерево что ли? и что там сложного? в общем, не понимаю.
Каюсь, каюсь...

Цитата:
Сообщение от mazzy Посмотреть сообщение
то, что у автора 2009 не значит, что не стоит учитывать и старшие версии.
читают то многие. а вопрос неплохой вроде.
Тогда нужно разделить совет по той версии, по которой спрашивают от совета по более старшим версиям. Вообще, если автор спрашивает про 2009 - то как бы и надо отвечать в первую очередь про 2009. Бонусом можно добавить про другие версии, но в первую очередь ответить надо человеку на тот вопрос, который он задал.

Цитата:
Сообщение от mazzy Посмотреть сообщение
раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))
ну тут не поспоришь - конечно надо делать нормальные классы.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: mazzy (2).
Старый 13.10.2016, 21:22   #14  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Альтернативный вариант - немного поменять взгляд на задачу. Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun. Если возвращаемая таблица во всех вариантах запроса одна, то можно инициализировать табличный курсор с помощью select noFetch и вернуть его.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
За это сообщение автора поблагодарили: mazzy (2), NetBus (2).
Старый 13.10.2016, 21:30   #15  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от mazzy Посмотреть сообщение
да, в аксапте иногда очень не хватает union, having и вложенных запросов.
Сергей, ты зачем пугаешь людей?

Union в Аксапте есть: https://msdn.microsoft.com/en-us/library/cc605991.aspx

Having и вложенные запросы можно эмулировать через промежуточные View.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
За это сообщение автора поблагодарили: mazzy (2).
Старый 13.10.2016, 21:35   #16  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Цитата:
Сообщение от sukhanchik Посмотреть сообщение

InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.
.
Данный пример практически полностью соответствует моей вводной задаче. Только таблица 'своя' , а наполнение и роль в системе практически идентичны.
Старый 13.10.2016, 21:36   #17  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос.
Посмотрите для примера на класс TradeLoopTrans. Пример его использования - метод CustInvoiceJour.queryCustInvoiceTrans и отчёт SalesInvoice метод fetch. Если я правильно понял вашу задачу, то в стандартных отчётах-документах по заказу/закупке реализовано нечто похожее.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 13.10.2016, 21:42   #18  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Ветвистая логика может означать, что при разных входных параметрах нужно использовать разные по сути запросы. Сами запросы могут быть и не всегда сложные. Вопрос в том чтобы отделить и инкапсулировать первичный отбор от последующей обработки.

Более общая формулировка задачи:
Как (с минимальными накладными затратами) результат (выход) одного алгоритма подать на вход следующего, так что бы алгоритмы не зависили от тонкостей реализации друг друга. Общего рецепта по-видимому нет. Когда-то будут более выгодны временные таблицы, когда-то квазивременные
Старый 13.10.2016, 21:45   #19  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Альтернативный вариант - немного поменять взгляд на задачу. Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun. Если возвращаемая таблица во всех вариантах запроса одна, то можно инициализировать табличный курсор с помощью select noFetch и вернуть его.
Это если логика отбора покрывается возможностями Query
За это сообщение автора поблагодарили: mazzy (2).
Старый 13.10.2016, 22:00   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать . Нужен автор с более детальным примером .
согласен )

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.
закольцованные через inventSettlement? тогда нужно больше одной таблицы )))
или ты лот возврата имеешь в виду. а как у него кольцо может образоваться?



Цитата:
Сообщение от Maxim Gorbunov Посмотреть сообщение
Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun.
да, но тут снова встает ограничение аксапты - на одно поле - одна агрегатная функция.
в результате получить отдельно дебетовые и кредитовые обороты в одном запросе по одной таблице становится проблематично.

хотя если можно использовать больше одного датасорса по одной таблице... )))


Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Более общая формулировка задачи:
Как (с минимальными накладными затратами) результат (выход) одного алгоритма подать на вход следующего, так что бы алгоритмы не зависили от тонкостей реализации друг друга. Общего рецепта по-видимому нет. Когда-то будут более выгодны временные таблицы, когда-то квазивременные
А объектно-ориентированное программирование? Не? )))

Один класс инкапсюлирует одно, другой класс - другое. они могут использовать друг-друга.

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

но надо оптимизировать не запрос. а систему в целом. которая работает в многопользовательском режиме.

если рассматривать систему в целом, то монстр-запросы как правило очень плохо влияют на среднюю отзывчивость сервера и среднюю производительность. в среднем лучше на SQL подавать несложные и однотипные запросы. даже если при этом получаются не самые минимальные resultSet'ы.
Теги
distinct, recordrefrencelist_ru, recordsortedlist, view

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Программное воссоздание записей SqlDictionary для определенной таблицы gl00mie DAX: Программирование 17 04.05.2023 20:13
Выборка произвольных записей одним запросом db DAX: Программирование 1 23.09.2010 14:15
Выбор записей по неизвестным заранее полям PavelSR DAX: Программирование 16 21.08.2006 16:16
Как добавить в фильтрацию записей доп. таблицы n:1 или 1:n? Hidden DAX: Программирование 6 11.08.2006 14:04
вывод количества записей в таблице на web форме и указание текущей страницы таблицы bambuk1960 DAX: Программирование 1 06.07.2006 13:27
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:47.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.