Как лучше хранить ссылки на записи - (RefTableId, Company, RefRecId)

[mazzy]

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

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

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


=====================
возможные варианты:

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. чтобы избавиться от контейнеров и от преобразований типов
недостатки нужно писать обертку, чтобы с этим было удобно работать

[fed]

8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то. По завершении процедуры просто тупо оттуда удаляем записи по условию.
Лично я бы, (не знаю как обосновать, просто по личному опыту) использовал бы вариант 5, если предполагается что будет обработано не больше 10 тысяч записей и вариант 8 во всех остальных случаях.

[mazzy]

Quote:

Originally Posted by fed

8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то.

Ой... вариант конечно.
но на нее будет тратится recid. надо будет не забывать ее чистить... в общем, куча гемора.

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

[AndyD]

Quote:

Originally Posted by mazzy

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

М..

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

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

PS Для 2012-й - использовать временные таблицы на SQL-сервере

[mazzy]

Quote:

Originally Posted by AndyD

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

Разве?
а точно ЛЮБОЕ изменение приводит к пересозданию контейнера? даже conpoke?

[CDR]

Ответ на вопрос

Quote:

Originally Posted by mazzy

а как лучше в Аксапте хранить ссылки на записи?

уж очень сильно зависит от

Quote:

Originally Posted by mazzy

потом как-то обрабатывает

К предложенным вариантам можно добавить сохранение во внешний файл (например, csv).

[AndyD]

И где в приведенной ссылке говорится о преобразовании значений к строковому типу?

Простой путь проверки - посмотреть в Management Studio значение блоб-поля SysLastValue.Value

[S.Kuskov]

Стандартная реализация квазивременной таблицы для хранения ссылок: RecordReferenceList_RU Выборка произвольных записей одним запросом
В той же теме mazzy сам давал ссылку и на другое схожее бсуждение axaptapedia: Tutorial Form MultiSelectCheckBox.

[mazzy]

Quote:

Originally Posted by S.Kuskov

Стандартная реализация квазивременной таблицы для хранения ссылок: RecordReferenceList_RU Выборка произвольных записей одним запросом
В той же теме mazzy сам давал ссылку и на другое схожее бсуждение axaptapedia: Tutorial Form MultiSelectCheckBox.

RecordReferenceList_RU - ссылки на одну таблицу.
в теме MultiSelectCheckBox также обсуждаются ссылки на одну таблицу.

[lev]

создал бы отдельную базу на SQL, с таблицей со всеми необходимыми полями. и использовал бы её для своих нужд

[sukhanchik]

Я за вариант 8.

Quote:

Originally Posted by fed

8. Забыл про квазивременную таблицу. То есть - обычную таблицу в БД с полями RefTableId,refRecId,refCompanyId, в которую добавлен, например id сессии или просто GUID-какой-то. По завершении процедуры просто тупо оттуда удаляем записи по условию.

Quote:

Originally Posted by mazzy

Ой... вариант конечно.
но на нее будет тратится recid. надо будет не забывать ее чистить... в общем, куча гемора.

Да, будут тратиться. А сильно жалко?
А с очисткой как раз все просто. Нужно просто только на какой-то момент иметь завершенную работу этой утилитки (как вариант - остановка АОС). И тогда Truncate Table отрабатывает быстро и на ура. Можно туда добавить поле, аналог кода сессии - типа утилитка отработала один раз - все записи отметились одним кодом. Утилитка отработала второй раз - новые записи отметились другим кодом и т.д. По этому коду сделать индекс и чистить по индексу. Это если хочется чистить сразу. А можно этим и не заморачиваться - а дождаться возможности выполнить Truncate Table

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

Пример 1. InventSumLogTTS. Ее можно честно чистить после остановке АОСа.
Пример 2. Batch. Там хранится туева хуча мусора, и в нее постоянно складываются записи. Раз в некий период (когда ну очень хочется уменьшить место, занимаемое базой) нужные записи переливаются в копию Batch, исходная таблица грохается, а копия выдается за оригинал.

[S.Kuskov]

Quote:

Originally Posted by mazzy

RecordReferenceList_RU - ссылки на одну таблицу.
в теме MultiSelectCheckBox также обсуждаются ссылки на одну таблицу.

А что мешает хранить не один объект а колекцию объектов RecordReferenceList_RU, например в том же Map(tableId, RecordReferenceList_RU)?

[mazzy]

ничего не мешает.
просто этот случай сводится к пункту 3.

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

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

[S.Kuskov]

Quote:

Originally Posted by mazzy

ничего не мешает.
просто этот случай сводится к пункту 3.

Я бы сказал, что это гибрид пунктов 3 и 8, т.к. для хранения данных RecordReferenceList_RU использует не оперативную память, а таблицу БД, что позволяет использовать для работы с ним join. Лично для меня это преимущество. А что будет преимуществом для вас я не знаю . От того как вы собираетесь обходить или обрабатывать записи и будет зависеть выбор варианта хранения/доступа к записям.

Quote:

Originally Posted by mazzy

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

А класс RecordReferenceList_RU как раз и инкапсулирует всю эту "неочивидную" логику, предоставляя стандартный интерфейс, который должен быть понятен пргограммисту.

[sukhanchik]

Quote:

Originally Posted by mazzy

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

Ну... не буду настаивать . Скажу лишь только то, что как раз с т.з. отладки всякие map-ы, set-ы и временные таблицы - причиняют гораздо большее неудобство, нежели постоянные таблицы.

[Alex_KD]

Quote:

Originally Posted by mazzy;253447

1. использовать временную таблицу
[B

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

TmpRecIdMap?
StrRef использовать под компанию.

[egorych]

Quote:

Originally Posted by sukhanchik

Ну... не буду настаивать . Скажу лишь только то, что как раз с т.з. отладки всякие map-ы, set-ы и временные таблицы - причиняют гораздо большее неудобство, нежели постоянные таблицы.

Это точно! Ладно, если нужно хранить 100, ну 1000 записей - можно и быстренько циклом пройтись по мапу! А если нужно ВСЕ - то альтернативы нормальной таблице ИМХО нет.
Тут вопрос в том, что мы (программисты имею ввиду) все равно (в конечном итоге) оперируем понятием ТАБЛИЦА - т.е. используем реляционную структуру. Все эти мапы, классы и т.д. ИМХО притянуты за уши (в Аксапте имею ввиду).

[mazzy]

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

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

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

===========================
Отдельно хотелось бы спросить - может у кого-нибудь есть опыт работы с recordLinkList? Вроде системный класс. И существует давно. Но практически не используется. Почему?

[gl00mie]

Quote:

Originally Posted by mazzy

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

Вопрос, по-моему, бессмысленный, если не указать, для чего отмечать записи, как будут использоваться ссылки (сразу вспоминаются "Алгоритмы и структуры данных" Вирта). Будут ли ссылки перебираться потом с сортировкой по компаниям, или по таблицам, или по возрастанию RecId в рамках таблицы? Или это будет случайный выбор с гауссовским распределением вероятности?.. Если бы ссылок было очень много, понятно, что можно было бы сделать таблицу и не заморачиваться этими вопросами - просто прикрутить нужные индексы. Но если ссылок будет немного, тогда выбор, скорее всего, падет на ядрёные классы-коллекции, а тут уже очень важно определиться с тем, что будет использоваться в качестве ключа. Выбор же ключа, очевидно, напрямую зависит от того, как будут использоваться данные. К слову, мне лично в последнее время нравится хранить во всяких там Map'ах записи временных таблиц: и на диск ничего не выпадает, в отличие от самих временных таблиц, и данные типизированы и понятны; контейнеры в этом плане я лично просто "не перевариваю".

Quote:

Originally Posted by S.Kuskov

Эх, LINQ для вас нету (в Axapte я имею в виду)

Кто сказал?
AxLINQ version 1.0
AX Developer tips: LINQ in X++
Dynamics Ax + LINQ

[mazzy]

Quote:

Originally Posted by gl00mie

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

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