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

[mazzy]

Zitat:

Zitat von gl00mie

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

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

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

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

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

Zitat:

Zitat von gl00mie

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

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

[S.Kuskov]

Zitat:

Zitat von mazzy

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

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

[mazzy]

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

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

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

[gl00mie]

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

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

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

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

[mazzy]

Zitat:

Zitat von gl00mie

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

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

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

[S.Kuskov]

Zitat:

Zitat von gl00mie

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

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

Zitat:

Zitat von gl00mie

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

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

[mazzy]

Zitat:

Zitat von S.Kuskov

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

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

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

[gl00mie]

Zitat:

Zitat von S.Kuskov

Zitat:

Zitat von gl00mie

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

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

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

[mazzy]

Zitat:

Zitat von gl00mie

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

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

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

[gl00mie]

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von gl00mie

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

[CDR]

Zitat:

Zitat von mazzy

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

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

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

[mazzy]

Zitat:

Zitat von CDR

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

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

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

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

[CDR]

Zitat:

Zitat von mazzy

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

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

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

[mazzy]

Zitat:

Zitat von CDR

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

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

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

[S.Kuskov]

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

[mazzy]

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

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

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

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

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

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

[CDR]

Zitat:

Zitat von mazzy

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

Zitat:

Zitat von mazzy

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

[S.Kuskov]

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

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

[mazzy]

Zitat:

Zitat von CDR

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

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

[S.Kuskov]

Zitat:

Zitat von mazzy

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

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