Фиксированные РУИДы для общих объектов

Объекты Гедымина за пределами файла базы данных идентифицируются РУИДом. РУИД присваивается при создании объекта под учетной записью Администратора или в момент записи в файл и состоит из ИД объекта и ИД базы. При перемещении объекта между базами его ИД изменится, а РУИД сохранится.

Для неотъемлемых частей платформы зарезервирован диапазон идентификаторов [0..147000000). ИД таких объектов одинаков во всех базах. При сериализации они получают РУИДы стандартного вида, где ИД базы равен 17.

Если для бизнес-класса существует натуральный потенциальный первичный ключ, то разработчик перекрывает функцию CheckTheSameStatement и возвращает запрос для отыскания объекта в БД. Для объекта, найденного в процессе загрузки из файла по потенциальному ключу, РУИД в базе данных заменяется на РУИД из файла.

Исторически так сложилось, что не всем объектам ядра платформы был присвоен фиксированный идентификатор. Кроме этого, фиксированные идентификаторы или РУИДы напрашиваются для общих элементов справочников: административно-территориальных единиц, валют, единиц измерения и т.п. Проблема была не столь заметна, пока разработка прикладных решений велась на единой базе данных. С переходом на пространства имен каждый разработчик может иметь автономную базу данных. Если не унифицировать РУИДы для общих объектов, то при каждой загрузке ПИ со сторонней базы данных они будут перезаписываться новыми значениями.

Какой выбор мы имеем на сегодняшний день:

1. Выявлять общие объекты и присваивать им фиксированные ИД. С помощью процедуры апгрейда структуры БД подменять ИД и РУИДы на существующих базах.
2. Выявлять общие объекты и включать их в ПИ нижнего уровня, от которых будут зависеть все прикладные решения. Для синхронизации РУИДов распространить ПИ с общими объектами на все базы разработчиков.
3. Реализовать механизм поддержки потенциальных ключей. Не формировать и не использовать РУИДы для объектов, которые могут быть идентифицированы через натуральный ключ.
4. Для объектов, идентифицируемых через натуральный ключ, вычислять РУИД с помощью хэш-функции.

Двум последним решениям с использованием натуральных ключей присущи все минусы натуральных ключей. Отклоняем.

Остается модифай или общие ПИ нижнего уровня. Первый вариант удобен тем, что даже у ленивого разработчика РУИДы обновятся после смены экзешника. Второй -- больше соответствует идеологии ПИ и совместной разработки ПО на платформе Гедымин. Не исключен и коомбинированный вариант.