Использование натуральных идентификаторов (например, адрес электронной почты)

Question

Есть ли конкретная причина, по которой вы не использовали бы естественный идентификатор, такой как адрес электронной почты?

В настоящее время я использую класс UUID Java для создания уникальных идентификаторов, но для некоторых объектов у них есть естественный ключ -как пользователь и его адрес электронной почты.Было бы больше смысла (и сделать мой код чище), если бы я использовал их адрес электронной почты, но мне было интересно, есть ли какая-то конкретная причина, по которой вы не должны?

Спасибо

ОБНОВЛЕНИЕ

Я использую MongoDB в данном конкретном случае.

Answer 1

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

Answer 2

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

Натуральные ключи должны быть уникальными и неизменными, и чем короче, тем лучше для соединения. В большинстве случаев целочисленный ключ с уникальным индексом естественного ключа будет работать лучше и его будет легче обслуживать в случае изменения ключа. Ключ GUID также может быть приемлемым, если вы выполняете репликацию или если вам нужно быть нейтральным к базе данных, но он, как правило, не будет работать так же хорошо, как целочисленный ключ.

Answer 3

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