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

Результаты опроса: Как лучше хранить ссылки на записи - (RefTableId, Company, RefRecId)
myTempTable - временная таблица 4 21.05%
recordLinkList 2 10.53%
map(DataAreaId, recordLinkList) 0 0%
set([refTableId, refRecId, refCompanyId]) 3 15.79%
map([refTableId, refCompanyId], set(refRecId)) 2 10.53%
map(refTableId, map(refCompanyId, set(refRecId))) 1 5.26%
другое - написал сообщение в теме 5 26.32%
не знаю/мне все равно 2 10.53%
Голосовавшие: 19. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.07.2011, 13:08   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Как лучше хранить ссылки на записи - (RefTableId, Company, RefRecId)
Предположим, есть какая-то программисткая утилита (это чтобы не уходить в обсуждение - можно сделать по-другому). Например, что-то типа хитро-умной проверки базы данных.

эта программисткая утилита:
= сначала просматривает ВСЕ записи изо всех хранимых таблиц (не временных) и изо всех компаний (реальных или виртуальных)
= во время просмотра ЗАПОМИНАЕТ где-то ссылки на записи в разных таблицах-компаниях
= потом как-то обрабатывает (например, обновляет или удаляет)

вопрос:
а как лучше в Аксапте хранить ссылки на записи?
при условии, что ссылки могут быть на разные таблицы и в разных компаниях (возможно в виртуальных)


=====================
возможные варианты:
  1. myTempTable
  2. recordLinkList
  3. map(DataAreaId, recordLinkList)
  4. set([refTableId, refRecId, refCompanyId])
  5. map([refTableId, refCompanyId], set(refRecId))
  6. map(refTableId, map(refCompanyId, set(refRecId)))
  7. другое

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

2. recordLinkList стандартный класс.
но не умеет работать с разными компаниями.
или умеет? кто-нибудь какой опыт работы с этой структурой у вас?
недостатки - только простой перебор записей при выборке из структуры. нет поиска и прямого позиционирования на нужную.

3. recordLinkList внутри map для каждой компании
недостатки - нужно писать обертку, чтобы с этим было удобно работать

4. хранить множество из контейнеров.
недостатки - внутреннее представление контейнера - строка. Поэтому все тройки будут хранится как строки. что плохо с точки зрения производительности и объема для хранения. кроме того, контейнеры нельзя типизировать, поэтому проверки придется делать runtime.

5. хранить несколько множеств в map. ключ в map - контейнер, ключ в set - refRecId
недостатки:
= нужно писать обертку, чтобы с этим было удобно работать
= у контейнера те же самые недостатки, что и в пункте 4

6. чтобы избавиться от контейнеров и от преобразований типов
недостатки нужно писать обертку, чтобы с этим было удобно работать
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 05.07.2011 в 16:24. Причина: убрал про преобразование типов. спасибо AndyD
Старый 05.07.2011, 13:16   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то. По завершении процедуры просто тупо оттуда удаляем записи по условию.
Лично я бы, (не знаю как обосновать, просто по личному опыту) использовал бы вариант 5, если предполагается что будет обработано не больше 10 тысяч записей и вариант 8 во всех остальных случаях.
Старый 05.07.2011, 13:36   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от fed Посмотреть сообщение
8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то.
Ой... вариант конечно.
но на нее будет тратится recid. надо будет не забывать ее чистить... в общем, куча гемора.

но согласен с тем, что просто временная таблица может тормозить при большом числе записей (больше нескольких десятков тысяч)
__________________
полезное на axForum, github, vk, coub.
Старый 05.07.2011, 13:38   #4  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Цитата:
Сообщение от mazzy Посмотреть сообщение
4. хранить множество из контейнеров.
недостатки - внутреннее представление контейнера - строка. Поэтому все тройки будут хранится как строки. что плохо с точки зрения производительности и объема для хранения.
М..

А с чего такое заключение?
Элементы контейнера хранятся точно так же, как переменные этого же типа

А по сути вопроса согласен с fed

PS Для 2012-й - использовать временные таблицы на SQL-сервере
__________________
Axapta v.3.0 sp5 kr2

Последний раз редактировалось AndyD; 05.07.2011 в 13:42.
Старый 05.07.2011, 13:47   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от AndyD Посмотреть сообщение
А с чего такое заключение?
Элементы контейнера хранятся точно так же, как переменные этого же типа
Разве?
а точно ЛЮБОЕ изменение приводит к пересозданию контейнера? даже conpoke?
__________________
полезное на axForum, github, vk, coub.
Старый 05.07.2011, 15:21   #6  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Ответ на вопрос
Цитата:
Сообщение от mazzy Посмотреть сообщение
а как лучше в Аксапте хранить ссылки на записи?
уж очень сильно зависит от
Цитата:
Сообщение от mazzy Посмотреть сообщение
потом как-то обрабатывает
К предложенным вариантам можно добавить сохранение во внешний файл (например, csv).
__________________
Dynamics AX Experience
Старый 05.07.2011, 16:07   #7  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
И где в приведенной ссылке говорится о преобразовании значений к строковому типу?

Простой путь проверки - посмотреть в Management Studio значение блоб-поля SysLastValue.Value
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: mazzy (5).
Старый 05.07.2011, 16:42   #8  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Стандартная реализация квазивременной таблицы для хранения ссылок: RecordReferenceList_RU Выборка произвольных записей одним запросом
В той же теме mazzy сам давал ссылку и на другое схожее бсуждение axaptapedia: Tutorial Form MultiSelectCheckBox.
Старый 05.07.2011, 17:30   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Стандартная реализация квазивременной таблицы для хранения ссылок: RecordReferenceList_RU Выборка произвольных записей одним запросом
В той же теме mazzy сам давал ссылку и на другое схожее бсуждение axaptapedia: Tutorial Form MultiSelectCheckBox.
RecordReferenceList_RU - ссылки на одну таблицу.
в теме MultiSelectCheckBox также обсуждаются ссылки на одну таблицу.
__________________
полезное на axForum, github, vk, coub.
Старый 05.07.2011, 21:28   #10  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
создал бы отдельную базу на SQL, с таблицей со всеми необходимыми полями. и использовал бы её для своих нужд
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 05.07.2011, 23:52   #11  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Я за вариант 8.
Цитата:
Сообщение от fed Посмотреть сообщение
8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то. По завершении процедуры просто тупо оттуда удаляем записи по условию.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Ой... вариант конечно.
но на нее будет тратится recid. надо будет не забывать ее чистить... в общем, куча гемора.
Да, будут тратиться. А сильно жалко?
А с очисткой как раз все просто. Нужно просто только на какой-то момент иметь завершенную работу этой утилитки (как вариант - остановка АОС). И тогда Truncate Table отрабатывает быстро и на ура. Можно туда добавить поле, аналог кода сессии - типа утилитка отработала один раз - все записи отметились одним кодом. Утилитка отработала второй раз - новые записи отметились другим кодом и т.д. По этому коду сделать индекс и чистить по индексу. Это если хочется чистить сразу. А можно этим и не заморачиваться - а дождаться возможности выполнить Truncate Table

Конечно остановка АОС - решение радикальное ... Но тут все зависит от того будут ли перерывы у утилитки, насколько сильно она будет увеличивать кол-во записей в этой таблице.

Пример 1. InventSumLogTTS. Ее можно честно чистить после остановке АОСа.
Пример 2. Batch. Там хранится туева хуча мусора, и в нее постоянно складываются записи. Раз в некий период (когда ну очень хочется уменьшить место, занимаемое базой) нужные записи переливаются в копию Batch, исходная таблица грохается, а копия выдается за оригинал.
__________________
Возможно сделать все. Вопрос времени
Старый 06.07.2011, 08:05   #12  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от mazzy Посмотреть сообщение
RecordReferenceList_RU - ссылки на одну таблицу.
в теме MultiSelectCheckBox также обсуждаются ссылки на одну таблицу.
А что мешает хранить не один объект а колекцию объектов RecordReferenceList_RU, например в том же Map(tableId, RecordReferenceList_RU)?
Старый 06.07.2011, 08:25   #13  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
ничего не мешает.
просто этот случай сводится к пункту 3.

===============
вообще говоря, я бы послушал ваши соображения какой вариант лучше какой хуже и почему

===============
насчет варианта 8 - хранить в постоянной таблице с идентификатором сессии
мне кажется, что это дико неочевидный вариант, который сильно усложнит дальнейшую поддержку и работу других программистов.
__________________
полезное на axForum, github, vk, coub.
Старый 06.07.2011, 08:55   #14  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от mazzy Посмотреть сообщение
ничего не мешает.
просто этот случай сводится к пункту 3.
Я бы сказал, что это гибрид пунктов 3 и 8, т.к. для хранения данных RecordReferenceList_RU использует не оперативную память, а таблицу БД, что позволяет использовать для работы с ним join. Лично для меня это преимущество. А что будет преимуществом для вас я не знаю . От того как вы собираетесь обходить или обрабатывать записи и будет зависеть выбор варианта хранения/доступа к записям.

Цитата:
Сообщение от mazzy Посмотреть сообщение
хранить в постоянной таблице с идентификатором сессии
мне кажется, что это дико неочевидный вариант, который сильно усложнит дальнейшую поддержку и работу других программистов.
А класс RecordReferenceList_RU как раз и инкапсулирует всю эту "неочивидную" логику, предоставляя стандартный интерфейс, который должен быть понятен пргограммисту.
За это сообщение автора поблагодарили: sukhanchik (2).
Старый 06.07.2011, 08:59   #15  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
насчет варианта 8 - хранить в постоянной таблице с идентификатором сессии
мне кажется, что это дико неочевидный вариант, который сильно усложнит дальнейшую поддержку и работу других программистов.
Ну... не буду настаивать . Скажу лишь только то, что как раз с т.з. отладки всякие map-ы, set-ы и временные таблицы - причиняют гораздо большее неудобство, нежели постоянные таблицы.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: egorych (1).
Старый 06.07.2011, 09:18   #16  
Alex_KD is offline
Alex_KD
Участник
AxAssist
MCBMSS
Соотечественники
 
522 / 362 (14) ++++++
Регистрация: 06.07.2006
Адрес: Melbourne, Down Under
Цитата:
Сообщение от mazzy;253447

1. использовать временную таблицу
[B
стандартных таблиц не вижу[/B]. скорее всего, придется создать новую.
достоинства - это почти обычная таблица с точки зрения программиста. может жить на сервере.
недостатки - с временными таблицами сложно работать и отлаживать
TmpRecIdMap?
StrRef использовать под компанию.
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0
Старый 06.07.2011, 09:26   #17  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ну... не буду настаивать . Скажу лишь только то, что как раз с т.з. отладки всякие map-ы, set-ы и временные таблицы - причиняют гораздо большее неудобство, нежели постоянные таблицы.
Это точно! Ладно, если нужно хранить 100, ну 1000 записей - можно и быстренько циклом пройтись по мапу! А если нужно ВСЕ - то альтернативы нормальной таблице ИМХО нет.
Тут вопрос в том, что мы (программисты имею ввиду) все равно (в конечном итоге) оперируем понятием ТАБЛИЦА - т.е. используем реляционную структуру. Все эти мапы, классы и т.д. ИМХО притянуты за уши (в Аксапте имею ввиду).
__________________
Axapta 3.0 sp - хз какой, kr2

Последний раз редактировалось egorych; 06.07.2011 в 09:30.
За это сообщение автора поблагодарили: S.Kuskov (1).
Старый 06.07.2011, 10:40   #18  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
со случаем, когда отмечается очень большое (больше нескольких десятков тысяч) записей, понятно - таблица.

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

См. также разбор случая для меток записей одной таблицы
axaptapedia: Tutorial Form MultiSelectCheckBox

===========================
Отдельно хотелось бы спросить - может у кого-нибудь есть опыт работы с recordLinkList? Вроде системный класс. И существует давно. Но практически не используется. Почему?
__________________
полезное на axForum, github, vk, coub.
Старый 07.07.2011, 10:27   #19  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
как лучше отмечать записи в разных таблицах, если предполагается, что отмеченных записей будет меньше нескольких десятков тысяч (в разных таблицах, в разных компаниях). Как правильнее хранить ссылки в этом случае?
Вопрос, по-моему, бессмысленный, если не указать, для чего отмечать записи, как будут использоваться ссылки (сразу вспоминаются "Алгоритмы и структуры данных" Вирта). Будут ли ссылки перебираться потом с сортировкой по компаниям, или по таблицам, или по возрастанию RecId в рамках таблицы? Или это будет случайный выбор с гауссовским распределением вероятности?.. Если бы ссылок было очень много, понятно, что можно было бы сделать таблицу и не заморачиваться этими вопросами - просто прикрутить нужные индексы. Но если ссылок будет немного, тогда выбор, скорее всего, падет на ядрёные классы-коллекции, а тут уже очень важно определиться с тем, что будет использоваться в качестве ключа. Выбор же ключа, очевидно, напрямую зависит от того, как будут использоваться данные. К слову, мне лично в последнее время нравится хранить во всяких там Map'ах записи временных таблиц: и на диск ничего не выпадает, в отличие от самих временных таблиц, и данные типизированы и понятны; контейнеры в этом плане я лично просто "не перевариваю".
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Эх, LINQ для вас нету (в Axapte я имею в виду)
Кто сказал?
AxLINQ version 1.0
AX Developer tips: LINQ in X++
Dynamics Ax + LINQ
За это сообщение автора поблагодарили: S.Kuskov (3).
Старый 07.07.2011, 10:57   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Вопрос, по-моему, бессмысленный, если не указать, для чего отмечать записи,
ну, почему же бессмысленный.
в такой постановке можно говорить о границах применимости. в каких случаях что лучше использовать.
__________________
полезное на axForum, github, vk, coub.
Теги
recid, запись, как правильно, ссылки

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: Long running process switches from one company to another company Blog bot DAX Blogs 0 27.01.2010 20:05
dynamicsaxtraining: Create new company. Demo data Blog bot DAX Blogs 0 19.11.2009 14:05
emeadaxsupport: Query execution failed for data set 'Company' Blog bot DAX Blogs 0 28.10.2009 00:06
Создание company, domain, virtual company из X++ DmitrySincerity DAX: Программирование 9 16.01.2009 18:17
Автоматическое увеличение значения поля при создании новой записи. sguryev DAX: Программирование 3 06.02.2003 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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