Что должно произойти со столбцом после удаления ограничения первичного ключа?

Question

Я говорю о нормализации первичного ключа. Допустим, мой столбец первичного ключа имеет тип nvarchar, что нарушает правила нормализации. После удаления ограничения первичного ключа и спецификации идентификатора из нужного столбца. Мне нужно создать новый столбец, который будет новым первичным ключом этой таблицы.

Мой вопрос: что должно случиться с предыдущим первичным ключом? У меня есть ответ, который звучит так: «столбец должен стать семантическим ключом», но я не могу понять этот ответ.

Answer 1

Первичный ключ - это не более чем уникальный индекс, который не может иметь значение NULL в качестве ключа.Как и любой из индексов, он может быть кластеризованным или некластеризованным.

Удаление кластеризованного индекса превращает таблицу в кучу с изменениями в структуре и поведении.Удаление некластеризованного индекса просто освобождает его пространство и не влияет на эту таблицу и другие индексы в таблице.

Так что после удаления у вас просто есть столбец (столбцы) с уникальными значениями, и вы можете рассмотретьих как семантический ключ, пока не будут вставлены некоторые повторяющиеся значения.

Answer 2

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

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

Например, допустим, у вас есть таблица сотрудников. Работодатель присваивает каждому сотруднику уникальный идентификационный номер сотрудника. Допустим, вы храните это значение в виде строки. Для пользователя это значение служит уникальным идентификатором, который относится к этому сотруднику. Между тем, ваша таблица может иметь числовой столбец, который служит уникальным идентификатором для этой записи.

create table Employee ( EmployeeRecordID int identity(1,1) primary key,
EmployerAssignedID nvarchar(12),
EmployeeName nvarchar(60),
Salary money )

insert into Employee ( EmployerAssignedID, EmployeeName, Salary ) values
( '#ABC100', 'Fred', 25000.12 ),
( '#AZZ314', 'Mary', 37700.00 ),
( '#MAA719', 'Fran', 34444.04 ),
( '#MZA977', 'Mary', 36000.00 ) 

При добавлении каждой записи SQL Server генерирует уникальный EmployeeRecordID для каждой записи, начиная с 1. Это ключ SURROGATE. В вашей базе данных и в вашем приложении вы будете использовать это значение для ссылки на запись.

Но когда ваше приложение связывается с пользователями, вы должны использовать EmployerAssignedID. Это СЕМАНТИЧЕСКИЙ первичный ключ. Для ваших пользователей имеет смысл использовать это значение для поиска конкретного сотрудника.