Идентификаторы записей
Каждая запись ДОЛЖНА иметь совершенно уникальный идентификатор. НЕ ДОЛЖНО быть возможности конфликта между идентификаторами для разных записей.
Это означает следующее:
- Никогда НЕ СЛЕДУЕТ допускать, чтобы две разных записи имели одинаковый идентификатор;
- После присвоения идентификатора какой-либо записи идентификатор НЕ СЛЕДУЕТ изменять.
В схеме минимальная длина идентификатора составляет 32 символа, а максимальная — 64 символа.
Издатели МОГУТ применять одну из следующих стратегий для создания идентификаторов записей.
Стратегии для создания идентификаторов
- Генерирование UUID для каждой записи, его хранение во внутренних системах и его обновление при каждом обновлении соответствующего элемента(-ов), образующего запись;
- Генерирование UUID в виде префикса, относящегося к издателю, и прикрепление к нему локального идентификатора элемента и идентификатора версии;
- Использование должным образом спроектированной хэш-функции, генерирующей идентификаторы на основе нормализованного представления записи в формате JSON (за исключением поля id) с низкой вероятностью конфликта.
- Использование внутреннего идентификатора в сочетании с уникальным префиксом во избежание конфликта между идентификаторами от разных издателей
Идентификаторы записей обычно предназначены для создания и внутреннего использования внутри приложений. В большинстве случаев их не нужно показывать пользователям. Это полностью отличается от идентификаторов субъектов или физических лиц, которые может быть полезно показывать пользователям.