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

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

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

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

В общем - используйте RecordReferenceList_RU и не мучайтесь
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: NetBus (2).
Старый 13.10.2016, 17:15   #2  
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   #3  
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, 20:25   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,286 / 3494 (123) ++++++++++
Регистрация: 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   #5  
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   #6  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,286 / 3494 (123) ++++++++++
Регистрация: 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:35   #7  
NetBus is offline
NetBus
Участник
 
200 / 85 (3) ++++
Регистрация: 08.07.2005
Адрес: Москва
Цитата:
Сообщение от sukhanchik Посмотреть сообщение

InventTrans
В свое время (АХ 4.0) у меня была задача поиска "закольцованных" движений. Соответственно, чтобы понять "кольцо" - нужно для каждой записи (каждого типа движения) применить свой алгоритм обработки. На выходе может получиться неопределенно много записей и тривиальный фильтр не подходит, соответственно ссылку на RecId найденных записей было удобно записывать в RecordReference_RU, а затем открывать стандартную форму InventTrans, отфильтрованную по отобранным движениям.
.
Данный пример практически полностью соответствует моей вводной задаче. Только таблица 'своя' , а наполнение и роль в системе практически идентичны.
Теги
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, время: 15:07.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.