Выбор записей из таблицы произвольным запросом

[NetBus]

Добрый день!
Есть задача выбрать из таблицы записи очень сложным запросом с ветвистой логикой, а по выбранным записям делать всевозможные преобразования. Хочется инкапсулировать процедуру поиска строк и потом использовать во всевозможных преобразованиях. Выбираю между (решения по убыванию приоритета предпочитаемости):

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

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

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

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

Axapta 2009

[Logger]

У вас задача как-то нечетко описана.
Непонятно что же именно нужно и как один пункт может заменить другой.
Например, как RecordSortedList заменит RecordRefrenceList_RU ?

Опишите тогда вашу задачу более детально.

[NetBus]

Есть таблица, из нее нужно выбрать по некоторому алгоритму строки.
Если все время писать while select и бороду условий - то это не есть гуд, хочется описать один раз и потом только пользоваться.
1. RecordRefrenceList_RU - заполняем RecordReferenceList_RU делаем join к таблице - работаем с записями
2. Заполняем RecordSortedList перебираем в цикле - работаем с записями
3. Временная таблица - надеюсь понятно

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

А также - расход памяти и невозможность впоследствии увидеть исторические результаты выборок.

Цитата:

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

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

А также - расход места на диске, который скорее всего не предназначен для хранения данных БД и увеличение времени выборки за счет отсутствия каких-либо индексов.

В общем - используйте RecordReferenceList_RU и не мучайтесь

[mazzy]

Цитата:

Сообщение от 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]

Цитата:

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

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

Оп! Категорически не согласен!

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

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

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

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

[mazzy]

Цитата:

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

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

особенно, если в наборе есть таблицы, для которых включен Valid Time State
https://msdn.microsoft.com/en-us/library/gg861781.aspx

[NetBus]

Всем спасибо за участие!
Познавательно, вспомнил еще способ
5. macros а ля InventDimJoin как в складском модуле.
Выбирай на любой вкус... ушел думать

[mazzy]

Цитата:

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

Всем спасибо за участие!
Познавательно, вспомнил еще способ
5. macros а ля InventDimJoin как в складском модуле.
Выбирай на любой вкус... ушел думать

макрос - это всего лишь синтаксический сахарн для запроса-монстра с бородой )

[NetBus]

Цитата:

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

макрос - это всего лишь синтаксический сахарн для запроса-монстра с бородой )

Да, полностью согласен, привёл до кучи и полноты картины.

[sukhanchik]

Цитата:

Сообщение от 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-ы и делать логику в семействе классов (т.е. создавать ряд классов, занимающихся обработкой и поиском; выносить общий код в классы-родители и т.д.)

[mazzy]

Цитата:

Сообщение от 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-ы на таблицы и / или в "приближенные к ним" классы.

раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))

[sukhanchik]

Цитата:

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

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

В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать . Нужен автор с более детальным примером .

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

сложная и ветвистая логика для справочника?
да, ну, брось...

да, я как-то незаметно стал ассоциировать "одну таблицу" со справочником. Каюсь.

Цитата:

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

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

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

Цитата:

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

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

Каюсь, каюсь...

Цитата:

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

то, что у автора 2009 не значит, что не стоит учитывать и старшие версии.
читают то многие. а вопрос неплохой вроде.

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

Цитата:

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

раз все равно придется делать классы, отвечающие за бизнес-сущности,
то может и не заморачиваться с "произвольным запросом"
а сразу сделать нормальные классы? ))))

ну тут не поспоришь - конечно надо делать нормальные классы.

[Maxim Gorbunov]

Альтернативный вариант - немного поменять взгляд на задачу. Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun. Если возвращаемая таблица во всех вариантах запроса одна, то можно инициализировать табличный курсор с помощью select noFetch и вернуть его.

[Maxim Gorbunov]

Цитата:

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

да, в аксапте иногда очень не хватает union, having и вложенных запросов.

Сергей, ты зачем пугаешь людей?

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

Having и вложенные запросы можно эмулировать через промежуточные View.

[NetBus]

Цитата:

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

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

Данный пример практически полностью соответствует моей вводной задаче. Только таблица 'своя' , а наполнение и роль в системе практически идентичны.

[Maxim Gorbunov]

Цитата:

Сообщение от Maxim Gorbunov

Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос.

Посмотрите для примера на класс TradeLoopTrans. Пример его использования - метод CustInvoiceJour.queryCustInvoiceTrans и отчёт SalesInvoice метод fetch. Если я правильно понял вашу задачу, то в стандартных отчётах-документах по заказу/закупке реализовано нечто похожее.

[S.Kuskov]

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

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

[S.Kuskov]

Цитата:

Сообщение от Maxim Gorbunov

Альтернативный вариант - немного поменять взгляд на задачу. Вместо того, чтобы возвращать записи, упаковкнные в какой-то контейнер, можно возвращать сформированный запрос. Например, в виде объекта Query или QueryRun. Если возвращаемая таблица во всех вариантах запроса одна, то можно инициализировать табличный курсор с помощью select noFetch и вернуть его.

Это если логика отбора покрывается возможностями Query

[mazzy]

Цитата:

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

В этом случае я сначала задаю уточняющие вопросы. Хотя тут они уже были заданы и без уточнений можно долго разглагольствовать . Нужен автор с более детальным примером .

согласен )

Цитата:

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

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

закольцованные через inventSettlement? тогда нужно больше одной таблицы )))
или ты лот возврата имеешь в виду. а как у него кольцо может образоваться?

Цитата:

Сообщение от Maxim Gorbunov

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

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

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

Цитата:

Сообщение от S.Kuskov

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

А объектно-ориентированное программирование? Не? )))

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

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

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

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