Рекомендации по ID для баз данных

Вы путаете внутреннюю функциональность базы данных с внешними критериями поиска.

Автоинкрементные суррогатные ключи полезны для внутреннего использования приложения. Никогда не передавайте их пользователю. Идентификация бизнес-объектов, будь то пользователь или счет, выполняется с помощью уникальной информации об объекте, такой как SSN, CCN или DOB. Используйте столько информации, сколько необходимо для уникальной идентификации объекта.

Я настоятельно рекомендую, чтобы, если вы должны предоставить какое-то новое значение идентификатора для каждого клиента, это НЕ было полем, с которым вы связываете все таблицы данных клиентов.

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

Сравнение SSN с автоматически увеличивающимися целыми числами — это яблоки и апельсины. Лично я избегаю GUID/UUID/UID, если только в таблице не будет так много записей, что использование целого числа станет неэффективным или неразумным.

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

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

Во всяком случае, меня смущают ваши сравнения между защищенными данными и автоинкрементными столбцами идентификаторов на основе целых чисел в пользовательских таблицах. Эти два типа данных никогда не должны смешиваться. Компания-эмитент вашей кредитной карты не должна использовать CCN в качестве первичного ключа в таблице базы данных, и правительство также не должно использовать ваше имя или SSN в качестве первичного ключа в своих таблицах базы данных.

Почему вы (или кто-либо другой) должны аутентифицировать пользователей, только знающих некоторые защищенные данные? Корпорациям больше не разрешено аутентифицировать пользователей на основе их SSN, и я знаю, что компания, выпускающая мою кредитную карту, не идентифицирует меня на основе моего CCN (тем более, что у меня их несколько, и номера карт в учетных записях менялись несколько раз). ).

Даже если вы реализовали UUID и сгенерировали какое-то произвольное случайное число, это все равно просто число. Аутентификация Active Directory использует идентификаторы GUID для своих идентификаторов, но также требует, чтобы пользователи предоставляли имена пользователей и пароли. Использование большего или меньшего типа данных в качестве столбца идентификатора не означает, что я могу умыть руки от какого-либо другого типа аутентификации или безопасности.

Вот какие последовательности предназначены для решения. Создайте объект, который можно атомарно увеличить за вставку. В некоторых БД это целое число с автоматическим приращением, а в других это объект последовательности, но идея та же, т.е. создать ключ, который не может конфликтовать и является уникальным.

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

В конце концов, способ проверить, действителен ли данный идентификатор пользователя, — это сама система. То есть ваша система является официальным источником этих идентификаторов. Является ли 555-45-9999 действительным SSN? Единственный способ узнать наверняка — попросить Службу социального обеспечения найти его и сопоставить с именем человека, утверждающего, что у него есть этот номер. Конечно, мы можем использовать схему идентификатора SSN, чтобы предварительно предположить, действительна ли она. Однако только поиск в их системе скажет нам наверняка. Потребность в контрольных цифрах может возникнуть в сильно распределенных системах, где, например, вы можете позволить другим людям генерировать номера, учитываемые вашей системой (например, транспортные компании, которые позволяют клиентам генерировать свои собственные номера для отслеживания). Поскольку именно ваша система будет автоматически генерировать идентификаторы, лучшее, что может сделать для вас контрольная цифра, — это помочь в элементарном способе проверки при вводе данных или поиске.