ID Best Practices для баз данных

Question

Мне было интересно, каковы лучшие практики для создания и хранения идентификаторов.Несколько лет назад профессор рассказал мне об опасностях плохо сконструированной системы удостоверений личности, используя в качестве примера номер социального страхования.В частности, из-за того, что в SSN нет обнаружения ошибок ... невозможно определить разницу между 9-значной строкой и действительным SSN.И теперь правительственным учреждениям нужны такие вещи, как Фамилия + SSN или День рождения + SSN, чтобы отслеживать ваши данные и обеспечивать их проверку.Кроме того, ваш номер социального страхования в некоторой степени предсказуем, исходя из того, где вы родились.

Сейчас я создаю базу данных пользователей ... и на основании этого совета "userid mediumint auto_increment" было бы неприемлемо.Особенно, если я планирую использовать этот идентификатор в качестве основного идентификатора для пользователя.(например, если я позволю пользователям изменять свое имя пользователя, то имя пользователя будет сложнее отслеживать, чем числовой идентификатор пользователя ... требующий каскадных внешних ключей и еще чего-то.) Электронные письма меняются, имена пользователей могут меняться, пароли меняются ..... но идентификатор пользователя должен оставаться постоянным всегда.

Ясно, что auto_increment предназначен только для surrogate_keys.Таким образом, это полезный ярлык, только когда у вас уже есть основной механизм идентификации, но его не следует использовать в качестве «врожденного идентификатора» для данных.Создание случайного UUID выглядит интересно, но случайность меня выключает.

И поэтому я спрашиваю: каковы лучшие практики для создания идентификационного номера "первичного ключа"?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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