Первичный и внешний ключ в то же время

Question

Можно ли в SQL Server 2008 иметь таблицу, созданную с двумя столбцами, которые являются одновременно первичными и внешними ключами? Если да, как выглядит такой код? Я искал и ничего не придумал.

Answer 1

Конечно, нет проблем:

CREATE TABLE dbo.[User] 
(
    Id int NOT NULL IDENTITY PRIMARY KEY, 
    Name nvarchar(1024) NOT NULL 
); 

CREATE TABLE [Group] 
(
    Id int NOT NULL IDENTITY PRIMARY KEY, 
    Name nvarchar(1024) NOT NULL 
); 

CREATE TABLE [UserToGroup] 
(
    UserId int NOT NULL, 
    GroupId int NOT NULL, 
    PRIMARY KEY CLUSTERED (UserId, GroupId), 
    FOREIGN KEY (UserId) REFERENCES [User] (Id) ON UPDATE NO ACTION ON DELETE CASCADE, 
    FOREIGN KEY (GroupId) REFERENCES [Group] (Id) ON UPDATE NO ACTION ON DELETE CASCADE 
); 

Это довольно широко используется для моделирования много-ко-многим отношений.

Answer 2

Это совершенно разные конструкции.

A Основной ключ используется для обеспечения уникальности внутри таблицы и является уникальным идентификатором для определенной записи.

A Запасной ключ используется для ссылочной целостности, чтобы убедиться, что значение существует в другой таблице.

Иностранный ключ должен ссылаться на первичный ключ в другой таблице.

Если вы хотите иметь внешний ключ, который также является уникальным, вы можете сделать ограничение FK и добавить уникальный индекс/ограничение в это же поле.

Для справки SQL Server позволяет FK ссылаться на UNIQUE CONSTRAINT, а также на поле PRIMARY KEY.

Answer 3

Только быстрое примечание - из страниц Microsoft (http://msdn.microsoft.com/en-us/library/ms189049.aspx) ...

«Ограничение внешнего ключа не должен быть связан только с ограничением первичного ключа в другой таблице, она также может быть определена для ссылки столбцы ограничения UNIQUE в другой таблице. "

Не используется часто, но полезно в некоторых случаях.

Answer 4

Это, вероятно, не очень хорошая идея, поскольку часто вы хотите разрешить дублирование внешних ключей в таблице. Даже если вы не сейчас, в будущем, вы могли бы, поэтому лучше не делать этого. См. Is it fine to have foreign key as primary key?