1:1外键约束

时间:2020-03-05 18:44:23  来源:igfitidea点击:

在事务SQL中,如何指定外键约束应为1:1关系?声明列UNIQUE是否足够?下面是我现有的代码。

CREATE TABLE [dbo].MyTable(
    [MyTablekey] INT IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
    [OtherTableKey] INT NOT NULL UNIQUE
        CONSTRAINT [FK_MyTable_OtherTable] FOREIGN KEY REFERENCES [dbo].[OtherTable]([OtherTableKey]),
    ...
    CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
    (
        [MyTableKey] 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

解决方案

回答

我们可以声明该列既是主键又是外键。这是用于"扩展"表的好策略,该表用于避免将可空列放入主表中。

回答

根据上面的代码,鉴于表中每个主键的唯一约束列也都是唯一的,因此唯一约束就足够了。此外,这还假定在[OtherTable]中,[OtherTableKey]列是该表的主键。

回答

具有UNIQUE和NOT NULL约束的外键列在另一个表中引用UNIQUE,NOT NULL列会创建1:(0 | 1)关系,这可能就是我们想要的。

如果存在真正的1:1关系,则第一个表中的每个记录在第二个表中都会有一个对应的记录,反之亦然。在这种情况下,我们可能只想制作一张表(除非我们需要进行一些奇怪的存储优化)。

回答

If there was a true 1:1 relationship, every record in the first table would have a corresponding record in the second table and vice-versa. In that case, you would probably just want to make one table (unless you needed some strange storage optimization).

这是非常不正确的。让我给你举个例子。我们有一个表CLIENT与表SALES_OFFICE具有1:1的关系,因为例如,系统的逻辑如此。我们是否真的将SALES_OFFICE的数据合并到CLIENT表中?并且是否需要另一个表将自身与SALES_OFFICE相关联?那么数据库标准化最佳实践和模式又如何呢?

A foreign key column with the UNIQUE and NOT NULL constraints that references a UNIQUE, NOT NULL column in another table creates a 1:(0|1) relationship, which is probably what you want.

答案的第一部分是正确的答案,而没有第二部分,除非第二表中的数据确实是属于第一表的信息,并且永远不会被其他表使用。

回答

@bosnic:

You have a table CLIENT that has a 1:1 relationship with table SALES_OFFICE because, for example, the logic of your system says so.

应用程序逻辑所说的和数据模型所说的是两件事。强制与业务逻辑代码建立这种关系没有错,但是在数据模型中却没有任何关系。

Would you really incorporate the data of SALES_OFFICE into CLIENT table?

如果每个CLIENT都有一个唯一的SALES_OFFICE,并且每个SALES_OFFICE都有一个唯一的CLIENT,则可以,它们应该在同一表中。我们只需要一个更好的名字。 ;)

And if another tables need to relate them selfs with SALES_OFFICE?

没有理由。由于CLIENT具有唯一的SALES_OFFICE,因此将其他表与CLIENT相关。

And what about database normalization best practices and patterns?

这是归一化。

公平地说,SALES_OFFICE和CLIENT显然不是1:1:1关系,而是1:N。希望SALES_OFFICE存在,可以为1个以上的客户提供服务,并且将继续存在(至少一段时间)而没有任何客户。

一个更现实的示例是SALES_OFFICE和ZIP_CODE。一个SALES_OFFICE必须恰好具有1个ZIP_CODE,并且即使两个SALES_OFFICE具有相同的ZIP_CODE,它们也不会共享ZIP_CODE的实例(因此,将ZIP_CODE更改为1不会影响另一个)。我们是否同意ZIP_CODE作为SALES_OFFICE中的一列?