我有一个两列作为主键的表。这两列也是引用同一张表的外键:
(这张表是前段时间离开公司的人创建的)
CREATE TABLE [dbo].[tblItemLink](
[ItemListID] [int] NOT NULL,
[ItemID] [int] NOT NULL,
CONSTRAINT [PK_tblItemList] PRIMARY KEY CLUSTERED
(
[ItemListID] ASC,
[ItemID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tblItemLink] WITH CHECK ADD CONSTRAINT [FK_tblItemLink_tblItemLink] FOREIGN KEY([ItemListID], [ItemID])
REFERENCES [dbo].[tblItemLink] ([ItemListID], [ItemID])
GO
ALTER TABLE [dbo].[tblItemLink] CHECK CONSTRAINT [FK_tblItemLink_tblItemLink]
GO
实际上,ItemID 指的是 tblItem.ItemID,而 ItemListID 在 DB 中的其他任何地方都找不到,但在应用程序中有相应的 enum。
主键是否有任何理由也是引用自身的外键(即一些未记录的性能改进),或者这只是一个错误?
最佳答案
我不知道为什么这会带来好处 - 所以我将选择选项 2 - 一个错误。
当然,如果它是同一个表中的不同列,那是有道理的,正如@Jignesh.Raj 指出的那样,这将形成某种层次结构。
有时,您甚至可能会在具有此类多列引用的同一个表中出现多个层次结构:
CREATE TABLE T (
GroupID int not null,
ItemID int not null,
ParentItemID int null,
constraint PK_T PRIMARY KEY (GroupID,ItemID),
constraint FK_T_Parent FOREIGN KEY (GroupID,ParentItemID) references T (GroupID,ItemID)
)
在上面,
GroupID
列始终引用自身。但正如我所说,对于您当前的表,其中两列都只引用自己,这是没有意义的。
关于sql - 外键引用同表中的主键,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16620893/