Показать сообщение отдельно
Старый 05.07.2011, 13:08   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Как лучше хранить ссылки на записи - (RefTableId, Company, RefRecId)
Предположим, есть какая-то программисткая утилита (это чтобы не уходить в обсуждение - можно сделать по-другому). Например, что-то типа хитро-умной проверки базы данных.

эта программисткая утилита:
= сначала просматривает ВСЕ записи изо всех хранимых таблиц (не временных) и изо всех компаний (реальных или виртуальных)
= во время просмотра ЗАПОМИНАЕТ где-то ссылки на записи в разных таблицах-компаниях
= потом как-то обрабатывает (например, обновляет или удаляет)

вопрос:
а как лучше в Аксапте хранить ссылки на записи?
при условии, что ссылки могут быть на разные таблицы и в разных компаниях (возможно в виртуальных)


=====================
возможные варианты:
  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. чтобы избавиться от контейнеров и от преобразований типов
недостатки нужно писать обертку, чтобы с этим было удобно работать
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 05.07.2011 в 16:24. Причина: убрал про преобразование типов. спасибо AndyD