Ваши ограничения базы данных должны быть понятными бизнес-правилам СУБД. Существует ли бизнес-правило, которое гласит, что никакие два студента не могут иметь одинаковую комбинацию имени и фамилии? Я полагаю, нет, поэтому не создавайте уникальный ключ для этих двух полей. Возможно, лучше не предполагать, а спросить эксперта в области бизнеса, например, офицер зачисления.
Обратите внимание, что строка в этой таблице является предложением I.e. что существует студент, зачисленный с именем «x» и фамилией «y» и идентификатором студента «z». Очевидно, что СУБД не имеет понятия о том, верно ли это утверждение в реальном мире. Что обычно происходит, так это наличие надежного источника для проверки данных. Предприятие уполномочит сотрудника (директора и т. Д.) На эту роль. Допустим, именно сотрудник по регистрации отвечает за проверку того, что «x y» является реальным человеком, что они имеют право на регистрацию, и этот человек является тем, кем они себя называют. Как правило, они требуют просмотра документов (сертификатов, паспорта и т. Д.), Получения справок, опроса лица, проверки публичных записей и т. Д. Конечно, сотрудник по регистрации может делегировать свои обязанности другим сотрудникам или нанять агента.
В какой-то момент они будут удовлетворены и для удобства выдают свой собственный идентификатор, студенческий билет. Ошибки действительно случаются, и может оказаться, что это значение не является уникальным, и в этом случае ответственный за зачисление будет отвечать за решение проблемы и выдавать нового студента. Возможно, они будут использовать программное обеспечение для создания ценности, чтобы смягчить против таких проблем. Студенческий билет будет выдан студенту и будет использоваться на предприятии для идентификации личности для удобства всех заинтересованных лиц. Им даже может быть выдан документ (например, удостоверение личности с фотографией), чтобы помочь в идентификации, на основании уровня доверия в данном контексте (например, может потребоваться предъявить удостоверение личности с фотографией, чтобы сдать экзамен). Если учащийся забудет свое удостоверение личности, потеряет выданные документы и т. Д., То регистрационный офис сможет получить его из записей, например, со ссылкой на копии документов, взятых в процессе проверки; они вряд ли будут использовать только имя и фамилию.
Дело в том, что доверенным источником идентификатора является сотрудник по регистрации от имени предприятия, а не база данных, СУБД или любое другое программное обеспечение, участвующее в процессе. Поэтому, вероятно, приемлемо сделать идентификатор студента единственным идентификатором для стентов в базе данных. Учтите, однако, что столбец автоинкремента, созданный на одной аппаратной сборке одной СУБД в пределах предприятия, вероятно, не подходит для распределения таких значимых значений идентификатора.