Я создаю приложение, которое будет использоваться некоторыми пользователями. Основываясь на бизнес-логике, пользователи будут идентифицироваться по их электронной почте, поэтому электронная почта не будет повторяться во всей системе. Вот выдержка из диаграммы классов 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;
Я думаю, придерживаясь соглашения и уменьшая потенциальные проблемы в будущем, продолжайте использовать идентификатор. Это не обязательно должно быть раскрыто. Я бы также сохранил то, что вы сделали, сделав письмо уникальным.






«Должно ли быть» зависит от ваших требований. Совершенно нормально использовать как уникальный числовой идентификатор, так и задавать уникальность поля электронной почты (как указано в первом фрагменте). Это помогает строить отношения между сущностью пользователя и другими сущностями, поскольку у них есть «простое» поле, которое затем используется для объединения таблиц.
Если бы вы использовали поле адреса электронной почты в качестве уникального идентификатора для этой сущности, это значение нужно было бы использовать во всех таблицах отношений. Я не уверен, произойдет ли это автоматически, но при изменении адреса позже вам пришлось распространить это изменение на все связанные таблицы. Чтобы избежать неприятностей, используйте числовой идентификатор — тот, который никогда не должен меняться и всегда ссылаться на один пользовательский объект.
Не путайте UNIQUE и PRIMARY KEY. УНИКАЛЬНОЕ значение может измениться, но PRIMARY KEY никогда не должен меняться, НО оба являются INDEX
Итак, для вашего случая электронная почта может измениться в вашей бизнес-логике или нет?
Если да, не добавляйте его как ПЕРВИЧНЫЙ КЛЮЧ, должен быть только УНИКАЛЬНЫЙ ИНДЕКС. В противном случае вы можете использовать его как PRIMARY KEY.
ИМХО, вы должны придерживаться числового идентификатора, это упрощает, если (например) изменится электронная почта.