Я хочу знать, существуют ли какие-либо недостатки между ссылочным отношением, использующим столбцы первичного ключа, и столбцами уникального ключа (в SQL Server ограничение внешнего ключа может ссылаться только на столбцы в первичном ключе или уникальном индексе).
Существуют ли различия в том, как анализируются запросы в конкретных системах БД (например, Microsoft SQL Server 2005), в зависимости от того, ссылается ли внешний ключ на первичный ключ, а не на уникальный ключ?
Обратите внимание, что я не спрашиваю о различиях между использованием столбцов разных типов данных для ссылочной целостности, объединений и т. Д.
Просто в качестве примера представьте БД, в которой есть «справочная таблица» dbo.Offices
:
CREATE TABLE dbo.Offices (
ID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_Codes PRIMARY KEY,
Code varchar(50) NOT NULL CONSTRAINT UQ_Codes_Code UNIQUE
);
Есть также таблица dbo.Patients
:
CREATE TABLE dbo.Patients (
ID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_Patients PRIMARY KEY,
OfficeCode varchar(50) NOT NULL,
...
CONSTRAINT FK_Patients_Offices FOREIGN KEY ( OfficeCode )
REFERENCES dbo.Offices ( Code )
);
Каковы недостатки таблицы dbo.Patients
и ее ограничения FK_Patients_Offices
, как в приведенном выше коде T-SQL, по сравнению со следующей альтернативной версией:
CREATE TABLE dbo.Patients (
ID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_Patients PRIMARY KEY,
OfficeID int NOT NULL,
...
CONSTRAINT FK_Patients_Offices FOREIGN KEY ( OfficeID )
REFERENCES dbo.Offices ( ID )
);
Очевидно, что для второй версии dbo.Patients
значения в столбце OfficeID
обновлять не нужно, если в значения в столбце Code
dbo.Offices
внесены изменения.
Также (очевидно) то, что использование столбца Code
dbo.Offices
для ссылок на внешний ключ в значительной степени отрицательно сказывается на цели столбца суррогатного ключа ID
- это чисто артефакт примера. [Есть ли лучший пример таблицы, для которой ссылки на внешний ключ могут разумно использовать не первичный ключ?]