Как использовать UUID, но оставаться совместимым с существующими идентификаторами БД?

Question

В настоящее время мы разрабатываем API для нашего продукта.API предоставляет доступ к графу, состоящему из отношений между типами, такими как пользователи, публикации и т. П.

Теперь на эти объекты ссылается идентификатор первичного ключа в нашей базе данных, но поскольку каждый объект находится в отдельностиТаблица, эти идентификаторы сталкиваются без информации о типе объекта (= таблица).

Может показаться, что это не проблема, но это действительно для нас - дизайн API становится намного более несовместимым с этими конфликтами ID/ введите информацию в неправильном месте.

Теперь возникла идея использования UUID, и, поскольку в будущем мы, вероятно, отойдем от базы данных SQL в хранилище K / V, это может быть не самой плохой идеей.Кроме того, UUID предлагают гораздо лучшую уникальность, а также будут лучше масштабироваться.Таким образом, реализация UUID в нашем API не будет худшей когда-либо с разных точек зрения.

Однако в течение переходного периода нам все еще нужно обращаться к объектам по идентификатору БД, а UUID должен генерироваться изid и позволяют выводить идентификатор из UUID наоборот.

Что-то вроде 550e8400-e29b-11d4-YYYY-XXXXXXXXXXXX пришло на ум, где X будет первичным ключом из БД, а YYYY будеткод для типа объекта.

Есть ли "правильный" способ сделать это?Могу ли я что-нибудь сломать с этим подходом?Сохранение дополнительной информации UUID полностью или частично на самом деле не вариант.

Спасибо за понимание, Филипп

Answer 1

По определению, суррогатный ключ не имеет отношения к самим данным.Таким образом, независимо от того, используете ли вы целое число или указатель, суррогатный ключ предполагает, что нет никаких средств для определения чего-либо о самой сущности исключительно из ключа.Именно из-за этого у вас должно быть уникальное ограничение на что-то другое в таблице, кроме суррогатного первичного ключа.Таким образом, я бы не пытался внедрить какую-либо информацию в новую схему суррогатного ключа.Вместо этого я бы сделал направляющие «уникальными» и использовал бы их как целочисленный ключ.Аргумент против попытки вставить информацию в руководство - простота и, следовательно, экономическая эффективность.Я сомневаюсь, что вы когда-нибудь будете использовать магию, испеченную в проводнике, но это будет больно создавать их.

Теперь под «уникальным» я намекаю на проблему с направляющими: они плохо индексируются.Хотя их уникальность является преимуществом, это также слабость в этом отношении.Распространенным решением является использование так называемого guid COMB, который заменяет часть guid значением datetime.Гид по-прежнему в основном уникален, но его часть теперь последовательная и будет хорошо индексироваться.

Answer 2

на ум приходят две вещи:

создайте одну последовательность и используйте ее для заполнения всех первичных ключей. Это не будет истинным UUID, но будет уникальным в текущей системе. (т. е. с вами все будет хорошо в одном случае, но обмен данными может быть проблемой с другими системами)

создать таблицу карт. что-то вроде EXTERNAL_KEY с internal_id, internal_table, external_id. Заполните это строкой из триггеров ON INSERT для каждой таблицы и используйте external_id в качестве UUID в вашем приложении.

Кстати, я бы настоятельно рекомендовал не создавать «интеллектуальный» ключ с подстроками для определенных значений и т. Д.

НТН

Answer 3

Может быть, я слишком упрощен, но если вы хотите изменить тип данных передаваемого идентификатора, как насчет создания вычисляемого столбца, введите varchar (?), Который содержит ServerName / Instance.db_name.schema_name.table_name.id.Уникальность гарантируется, если имя сервера / экземпляра является уникальным для вашей среды, базы данных для вашего экземпляра, схемы для вашей базы данных, таблицы для вашей схемы и идентификатора для вашей таблицы - все они должны быть.

У меня нет НИКАКИХ проблем с нормализацией данных для такого рода использования.У меня огромная проблема с тем, что кто-то использует поле, подобное этому, чтобы задавать вопросы - в коде - например, давать мне все записи, которые пришли с Server02.Это было бы строковое поле и не было бы таким доступным для поиска, как GUID, но, я подозреваю, что в зависимости от того, где и как они хранятся вне исходной таблицы, это будет меньше причиной дефрагментации в индексахк которому они принадлежат.

• для "упорядоченных" направляющих на сервере sql см. Создание и изменение столбцов идентификаторов

  CREATE TABLE dbo.Globally_Unique_Data (уникальный идентификатор guid CONSTRAINT Guid_Default DEFAULT NEWSEQUENTIALID () ROWGUIDCOL, Employee_Name varchar (60) CONSTRAINT Guid_PK ПЕРВИЧНЫЙ КЛЮЧ (guid));

Answer 4

Я не знаю каких-либо конкретных проблем, но одна рекомендация будет использовать GUID версии 4 :

UUID версии 4 имеют вид xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx с любыми шестнадцатеричными цифрами для х, но только один из 8, 9, A или B для y. например f47ac10b-58cc- 4 372- a 567-0e02b2c3d479.

Вы можете поместить свои данные в «случайные» разделы. Просто заявите, что у вас есть действительно мусорный генератор случайных чисел. Вы также можете включить контрольную сумму для защиты от коллизий, связанных с повреждением данных, поскольку числовые идентификаторы GUID будут находиться рядом друг с другом.