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

[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'ах записи временных таблиц: и на диск ничего не выпадает, в отличие от самих временных таблиц, и данные типизированы и понятны; контейнеры в этом плане я лично просто "не перевариваю".