Как лучше хранить ссылки на записи - (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 сделать свойство, возвращающее идентификатор таблицы...