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

[mazzy]

Цитата:

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

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

Не-не-не... Вопрос наоборот - какой ключ лучше выбирать для того или иного ядерного класса? И кстати, почему для ядерного класса? Тут предлагали экстремальные варианты с хранением в текстовом файле и/или во внешней таблице.

не понимаю как выбор ключа зависит от будущего использования.
есть три ключевых поля - (RefTableId, Company, RefRecId).
эти поля единственным образом указывают на конкретную запись.
как и что тут можно выбирать?

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

или я чего-то не понимаю?

Цитата:

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

К слову, мне лично в последнее время нравится хранить во всяких там Map'ах записи временных таблиц

а какой ключ стоит использовать в map'ах?
(помним, что уникально определяют запись три поля (RefTableId, Company, RefRecId))

[S.Kuskov]

Цитата:

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

не понимаю как выбор ключа зависит от будущего использования.
есть три ключевых поля - (RefTableId, Company, RefRecId).
эти поля единственным образом указывают на конкретную запись.
как и что тут можно выбирать?

Ну как минимум можно выбирать между
map(Company, map(RefTableId, set(RefRecId)))
map(RefTableId, map(Company, set(RefRecId)))

[mazzy]

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

какие плюсы и минусы видите ВЫ у этих вариантов?
какие варианты и в каких случаях использовали бы Вы?

=====================
Еще раз:
я не спрашиваю что использовать в моем проекте.
я хотел бы обсудить сами варианты.

[gl00mie]

Цитата:

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

Вопрос наоборот - какой ключ лучше выбирать для того или иного ядерного класса?

Я, наверно, сегодня особенно туплю Лучше с какой точки зрения? Исходя из каких задач по использованию хранимых данных?

Цитата:

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

И кстати, почему для ядерного класса?

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

Цитата:

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

Тут предлагали экстремальные варианты с хранением в текстовом файле и/или во внешней таблице.

Почему бы нет? Можно еще с использованием стеганографии по какой-нить картинке данные размазать, и чем это будет не вариант для формулировки "потом [утилита] как-то обрабатывает"?

Цитата:

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

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

Цитата:

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

есть три ключевых поля - (RefTableId, Company, RefRecId). эти поля единственным образом указывают на конкретную запись.

Я, вероятно, захотел бы сгруппировать данные по компаниям, чтобы минимизировать число [очень тормознутых] переключений между ними - это один вариант. А, может, мне нужны только сами по себе записи без других данных из соотв. компаний, тогда я могу прописать код компании в свойство company() табличного буфера и выбирать записи из другой компании, не переключаясь в нее, - это другой вариант. А, может, я хочу сделать уникальный индекс по RecId без кода компании в нем, зная, что Аксапта выделяет RecId для таблицы в целом, и ищу записи в разных компаниях, которые могли бы нарушить уникальность этого индекса (мало ли, записи могли быть созданы прямыми SQL-запросами) - это третий вариант...

Цитата:

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

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

ну да, сортируйте пузырьком, и будет вам счастье...

Цитата:

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

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

"в действительности все не так, как на самом деле". Сдаюсь...

Цитата:

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

а какой ключ стоит использовать в map'ах?
(помним, что уникально определяют запись три поля (RefTableId, Company, RefRecId))

Внимание, вопрос: с какого перепуга меня должна в текущей формулировке задачи волновать уникальность комбинаций {RefTableId, Company, RefRecId} ? По мне так в качестве ключа при вставке в Map вполне прокатит map.elements(). Другое дело, если информацию о записях надо обрабатывать в какой-то последовательности... но об этом ведь ничего не сказано.

PS. А почему бы не хранить записи в виде Map [companyId -> RecordSortedList]?.. хотя какой-то идиот не догадался для RecordSortedList сделать свойство, возвращающее идентификатор таблицы...

[mazzy]

Цитата:

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

PS. А почему бы не хранить записи в виде Map [companyId -> RecordSortedList]?.. хотя какой-то идиот не догадался для RecordSortedList сделать свойство, возвращающее идентификатор таблицы...

об этом и речь.
Map [companyId -> RecordSortedList] не позволяет хранить данные из разных таблиц.

ок. я понял. поррасуждать чисто теоретически желающих нет.

[S.Kuskov]

Цитата:

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

в качестве ключа при вставке в Map вполне прокатит map.elements().

Тогда уж вместо Map можно использовать Set, вариант 4.

Цитата:

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

хотя какой-то идиот не догадался для RecordSortedList сделать свойство, возвращающее идентификатор таблицы...

Можно вместо RecordSortedList взять SysRecordSortedList. TableId там уже запоминается. Остаётся добавить добавить public метод getTableId.

[mazzy]

Цитата:

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

Можно вместо RecordSortedList взять SysRecordSortedList. TableId там уже запоминается. Остаётся добавить добавить public метод getTableId.

мысль интересная.
правда SysRecordSortedList тоже хранит записи из одной таблицы.
переменная tableid одна для всех записей.

еще есть класс SysRecordSubset, который хранит recid в контейнере.

[gl00mie]

Цитата:

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

Цитата:

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

По мне так в качестве ключа при вставке в Map вполне прокатит map.elements()

Тогда уж вместо Map можно использовать Set, вариант 4.

Map с "незначащим" целочисленным ключом и произвольным типом значений и Set с тем же самым типом значений - это отнюдь не одно и то же с точки зрения производительности. Set, как и Map, сортирует значения ключа, поэтому если в нем хранить, к примеру, записи таблицы, то он, я так понимаю, будет сортировать их по всем полям, что может оказаться совершенно излишне.

[mazzy]

Цитата:

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

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

Я кажется только въехал, почему мы друг друга не понимаем.
В самом начале, и в названии темы я говорил про ССЫЛКИ НА записи.

Нет необходимости хранить сами записи.

[gl00mie]

Цитата:

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

В самом начале, и в названии темы я говорил про ССЫЛКИ НА записи. Нет необходимости хранить сами записи.

Это я понял, но коль скоро мы говорим "вообще", то...

Цитата:

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

мне лично в последнее время нравится хранить во всяких там Map'ах записи временных таблиц: и на диск ничего не выпадает, в отличие от самих временных таблиц, и данные типизированы и понятны; контейнеры в этом плане я лично просто "не перевариваю".

[CDR]

Цитата:

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

Тут предлагали экстремальные варианты с хранением в текстовом файле...

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

Миллион раз отсортировать мап/сет - это уже действительно экстремальный вариант, особенно если последующая обработка еще будет и выполняться последовательно.

[mazzy]

Цитата:

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

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

Если последующая обработка будет выполняться последовательно, то миллион раз отсортировать мап/сет - это уже действительно экстремальный вариант.

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

Как бы ни выполнялась обработка - последовательно или в произвольном порядке - не думаю, что наличие дублей в выборке предполагается хоть кем-то. А обеспечивать уникальность ДО записи... Все равно потребуется мап/сет/таблица с сортировкой

[CDR]

Цитата:

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

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

Как бы ни выполнялась обработка - последовательно или в произвольном порядке - не думаю, что наличие дублей в выборке предполагается хоть кем-то. А обеспечивать уникальность ДО записи... Все равно потребуется мап/сет/таблица с сортировкой

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

[mazzy]

Цитата:

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

А в исходной постановке задачи разве предполагается, что возникнет дублирование?

Хороший вопрос. В конкретном исходом вопросе указания не было.

Если же рассуждать теоретически, в целом,
то стоит исходить из того, что дубли будут.

[S.Kuskov]

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

[mazzy]

а вот этого не очень понимаю.

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

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

некие записи по условию отбираются для дальнейшей обработки (поправить/изменить/скопировать/удалить)

в этом случае дубли обрабатывать не надо.

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

[CDR]

Цитата:

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

Если же рассуждать теоретически, в целом,
то стоит исходить из того, что дубли будут.

Цитата:

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

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

[S.Kuskov]

Пример:
В выборке есть дублирующие записи. Задача - сделать их уникальными, поместив в новое поле уникальное значение.

To CDR: Учитывать что дубли есть и обрабатывать их - это разные вещи

[mazzy]

Цитата:

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

S.Kuskov правильно сказал - если нужно работать с дублями, то будет не тройка значений (RefTableId, Company, RefRecId), а четверка-пятерка-и-так-далее. Т.е. добавляете еще одно поле и снова работаете с уникальными значениями.

Без потери общности вполне достаточно предположить, что хранятся уникальные тройки (RefTableId, Company, RefRecId)

[S.Kuskov]

Цитата:

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

Без потери общности вполне достаточно предположить, что хранятся уникальные тройки (RefTableId, Company, RefRecId)

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