Создание цифровых ключей на основе уникальных имен объектов в базе данных в разных системах?

Question

У меня есть база данных, которая использует уникальные текстовые ключи для связи между объектами. Например, когда вставляются пользователи, они вставляются с текстовым ключом «{date} - {system} - {user}», где каждый элемент ключа является буквенно-цифровым. Затем это проверяется с помощью таблицы поиска, чтобы увидеть, существует ли она, если нет, она вставляется в таблицу и создается целочисленный ключ с автоинкрементом. В противном случае используется тот же самый целочисленный ключ.

Затем, если вставлен уникальный атрибут этого пользователя, он сопоставляется и назначается цифровому ключу пользователя в качестве внешнего ключа. Например, документ, уникальный для этого пользователя, вставляется с ключом пользователя "{date} - {system} - {user}" и уникальным текстовым ключом для документа "{date} - {system} - {user- {document } "из которого генерируется целочисленный ключ.

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

Проблема в том, что ключи, конечно, не одинаковы в разных системах в зависимости от того, как и когда были вставлены элементы. Итак, моей первоначальной мыслью было использование хэша в качестве сгенерированного ключа, но я думаю, что int и bigint довольно ограничены.

Я не уверен, как SQL-сервер будет обрабатывать длинные строки хэшей для внешних ключей, я читал, что это не очень хорошо с точки зрения производительности. В противном случае я мог бы просто использовать текст, который создает сам ключ.

Как бы вы убедились, что ключи int, bigint или string (если это возможно) уникальны для всех систем, если предположить, что текстовый ключ уникален? Хэш? GUID? Как можно обрабатывать коллизии хэшей, если используется битовый ключ bigint (63 бита?), Если вообще используется?

Спасибо!

Answer 1

Джон, вы могли бы, если возможно, переосмыслить архитектуру ключей, потому что это идеальная ситуация для использования GUID для ключа. Таким образом, вы можете сгенерировать уникальный ключ для любого пользователя в любой системе и быть на 99.999999999999 .......% гарантированным, что никаких столкновений не будет. И это тоже всего 16 байтов. Вы всегда можете сохранить существующую структуру ключей как другой столбец, но, возможно, только для других целей, чтобы не идентифицировать или не сделать запись уникальной. Я полагаю, что это будет иметь место только в том случае, если ваше приложение использует эту информацию для выполнения определенных задач, а если нет, полностью избавится от нее.

Преимущество использования GUID в качестве ключа в этом сценарии заключается в том, что он не зависит от платформы, т.е. Вы можете использовать его на Oracle, SQL Server, Unix, Windows ....