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