Полезно ли иметь аннотацию @Id под такими атрибутами, как имя пользователя или адрес электронной почты пользователя?

Question

Какие сложности могут возникнуть при установке атрибутов @Id для файла, отличного от идентификатора, например

@GeneratedValue(strategy=GenerationType.AUTO)
@Column(name="user_id")
private Integer user_id;

@Id
@Size(min=6,message="email is too short")
@Pattern(regexp = "^.+@.+\\..+$",message="invalid email")
@Column(name="user_email")
private String user_email;

В моем пользовательском классе pojo: если я не определяю аннотацию идентификатора для user_id, а вместо этого для user_email, это создаст какие-либо сложности в долгосрочной перспективе?

Answer 1

Сначала позвольте мне сказать: это хороший вопрос!Краткий ответ на него:

Нет , не рекомендуется комментировать такие поля, как user_email или username с помощью @Id.

Для более глубокого изучения Почему , давайте сначала вспомним, как определяется первичный ключ (PK).В большинстве систем баз данных, ориентированных на SQL, определение PK соответствует по крайней мере двум предположениям, при которых PK всегда имеет вид:

• (i) NOT NULL
• (ii) УНИКАЛЬНЫЕ

Последствия для вашей идеи / вопроса:

• (a):

  A username илиЗначение user_email должно быть установлено в User экземпляр, прежде чем вы сможете сохранить его в базе данных.В этом случае он отсутствовал или был известен только в более поздний момент времени: постоянство = невозможно.И наоборот, для него никогда не может быть установлено значение unknown , то есть null, например, если пользователь просто не может предоставить свой адрес электронной почты (хотя это редкий случай в 2018 году).

• (b):

  Фактические значения для username / user_email, как правило, являются уникальными в большинстве приложений.Тем не менее, в бизнес-логике приложения, которую вы должны были бы убедиться, никто другой пользователь не вводит уже существующий / известный username / user_email дважды.Если вы аннотировали @Id, снова: Постоянство = невозможно.Тем не менее, наиболее вероятно, что использование дубликатов в одном из этих полей нарушит его семантику.

Если вы аннотируете user_id как поле @Id: в обоих случаях нет боли.

В контексте ORM документ спецификации JPA расширяет это определение и сообщает на странице 31:

Значение его первичного ключа уникально идентифицирует экземпляр сущности в контексте постоянства и для операций EntityManager, как описано в главе 3 «Операции с сущностями».Приложение не должно изменять значение первичного ключа.Поведение не определено, если это происходит.

Это приводит к следующему выводу

• (c)

  По определению, вы не можетена изменить значения полей @Id программно / во время выполнения.Управление такими полями должно оставаться исключительно на стороне объектно-реляционного преобразователя, реализующего спецификацию JPA.

Как указано в ответе Bohemian , username или user_email могут быть изменены в течение срока действия вашего приложения.Причина: данные изменчивы с точки зрения пользователя приложения.Пользователи могут захотеть изменить эти свойства (когда-нибудь в будущем), например, если они поженятся или поменяют своего поставщика электронной почты.

Тем не менее, обычно можно аннотировать поля типа String (и другие) см. стр.31:

Простой первичный ключ или поле или свойство составного первичного ключа должно быть одного из следующих типов: любой Java primitive type;любой примитивный тип обертки;java.lang.String;java.util.Date;java.sql.Date;java.math.BigDecimal;java.math.BigInteger.

Так что можно соблазниться и сказать: ну, давай с этим!Однако следует отступить назад и отразить, что (a) домен или (b) предполагаемые варианты использования приложения накладывают на схему базы данных предполагаемого приложения.Как уже говорилось выше, это особенно важно в вашем сценарии.

Имея в виду эти соображения "реального мира", вам лучше всего аннотировать @Id суррогатным ключом, таким как user_idв вашем примере °.Это не изменится на протяжении всей жизни вашей базы данных.Вопрос: почему это не изменится?Ответ: Нет практической причины для удовлетворения бизнес-ситуации, определенной пользователями приложения.

Надеюсь, это поможет.

° Подсказка

Лучше использовать Long вместо Integer с самого начала;Таким образом, у вас будет достаточно значений первичных ключей, которые не будут использоваться в качестве разработчика SW (верно для> 99,5% всех приложений).

Answer 2

Это плохая практика.

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