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

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

Я читал, как люди реализуют это с помощью Symfony 4 и Doctrine ORM, и все позволяют Doctrine создавать числовой идентификатор для идентификатора объекта. Основываясь на моей схеме, я должен это сделать?

Вот что у меня есть на данный момент:

 /**
 * @ORM\Entity(repositoryClass = "App\Repository\UserRepository")
 * @UniqueEntity(
 *     fields = "email",
 *     message = "error.email_already_registered"
 * )
 */
class User implements UserInterface
{
    /**
     * @ORM\Id()
     * @ORM\GeneratedValue()
     * @ORM\Column(type = "integer")
     */
    private $id;

    /**
     * @ORM\Column(type = "string", length=180, unique=true)
     * @Assert\NotBlank
     * @Assert\Email
     * @Assert\Length(min=4,max=180)
     */
    private $email;

Должен ли он быть похож на следующий код?

/**
 * @ORM\Entity(repositoryClass = "App\Repository\UserRepository")
 */
class User implements UserInterface
{
    /**
     * @ORM\Column(type = "string", length=180)
     * @ORM\Id()
     * @Assert\Email
     * @Assert\Length(min=4,max=180)
     */
    private $email;

ИМХО, вы должны придерживаться числового идентификатора, это упрощает, если (например) изменится электронная почта.

Nigel Ren 09.07.2019 08:41

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

MylesK 09.07.2019 09:12
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
0
2
69
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

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

Если бы вы использовали поле адреса электронной почты в качестве уникального идентификатора для этой сущности, это значение нужно было бы использовать во всех таблицах отношений. Я не уверен, произойдет ли это автоматически, но при изменении адреса позже вам пришлось распространить это изменение на все связанные таблицы. Чтобы избежать неприятностей, используйте числовой идентификатор — тот, который никогда не должен меняться и всегда ссылаться на один пользовательский объект.

Не путайте UNIQUE и PRIMARY KEY. УНИКАЛЬНОЕ значение может измениться, но PRIMARY KEY никогда не должен меняться, НО оба являются INDEX

Итак, для вашего случая электронная почта может измениться в вашей бизнес-логике или нет?

Если да, не добавляйте его как ПЕРВИЧНЫЙ КЛЮЧ, должен быть только УНИКАЛЬНЫЙ ИНДЕКС. В противном случае вы можете использовать его как PRIMARY KEY.

Другие вопросы по теме