SQL Server 2008：如何将FK设置为​​PK？

Question

我正在整理自己的数据库，从我见过的示例来看，外键也可以设置为主键。

我正在创建我的桌子，以便我所有的 FK 也都是 PK。这是错误的吗？什么时候FK应该成为PK？一定要PK吗？

主键在它们自己的表中有意义...作为 Id 和 Identity。但是当使用的Id是另一个表时，它也必须是PK吗？

Answer 1

当您尝试创建 1 到 1 或 1 到 0/1 映射时，外键只能作为主键。

示例：

我有一个“人员”表、一个“雇员”表和一个“承包商”表。所有员工都是人，所有承包商都是人，每个人要么是员工，要么是承包商

本质上你最终会得到这样的结果。

---

为了响应您的人员有多个地址，您应该创建一个关联表。这是一个图表。

正如您所看到的，现在每个人都可以有多个地址，并且由于每个员工都是一个人，因此每个员工可以有多个地址地址。对于承包商来说也是如此。

---

编辑：这是来自 SQL Server 的更改脚本

BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Address
    (
    AddressId bigint NOT NULL,
    Address nvarchar(50) NULL,
    City nvarchar(50) NULL,
    State nvarchar(50) NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.Address ADD CONSTRAINT
    PK_Address PRIMARY KEY CLUSTERED 
    (
    AddressId
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.Address SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Person
    (
    PersonId bigint NOT NULL,
    Name nvarchar(50) NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.Person ADD CONSTRAINT
    PK_Person PRIMARY KEY CLUSTERED 
    (
    PersonId
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.Person SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.PersonAddress
    (
    PersonId bigint NOT NULL,
    AddressId bigint NOT NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
    PK_PersonAddress PRIMARY KEY CLUSTERED 
    (
    PersonId,
    AddressId
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
    FK_PersonAddress_Person FOREIGN KEY
    (
    PersonId
    ) REFERENCES dbo.Person
    (
    PersonId
    ) ON UPDATE  NO ACTION 
     ON DELETE  NO ACTION 

GO
ALTER TABLE dbo.PersonAddress ADD CONSTRAINT
    FK_PersonAddress_Address FOREIGN KEY
    (
    AddressId
    ) REFERENCES dbo.Address
    (
    AddressId
    ) ON UPDATE  NO ACTION 
     ON DELETE  NO ACTION 

GO
ALTER TABLE dbo.PersonAddress SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Employee
    (
    EmployeeId bigint NOT NULL,
    EmployeeNumber nvarchar(50) NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.Employee ADD CONSTRAINT
    PK_Employee PRIMARY KEY CLUSTERED 
    (
    EmployeeId
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.Employee ADD CONSTRAINT
    FK_Employee_Person FOREIGN KEY
    (
    EmployeeId
    ) REFERENCES dbo.Person
    (
    PersonId
    ) ON UPDATE  NO ACTION 
     ON DELETE  NO ACTION 

GO
ALTER TABLE dbo.Employee SET (LOCK_ESCALATION = TABLE)
GO
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Contractor
    (
    ContractorId bigint NOT NULL,
    ContractorNumber nvarchar(50) NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.Contractor ADD CONSTRAINT
    PK_Contractor PRIMARY KEY CLUSTERED 
    (
    ContractorId
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.Contractor ADD CONSTRAINT
    FK_Contractor_Person FOREIGN KEY
    (
    ContractorId
    ) REFERENCES dbo.Person
    (
    PersonId
    ) ON UPDATE  NO ACTION 
     ON DELETE  NO ACTION 

GO
ALTER TABLE dbo.Contractor SET (LOCK_ESCALATION = TABLE)
GO
COMMIT

Answer 2

只有一种情况需要 FK 兼 PK。

当该表表示 PK 表中事物的子类或子集时，例如，SalariedEmployees 表具有与Employees 表的FK...

Answer 3

FK是指向另一个表的PK的字段。就是这样。
链接到自身的表可以包含指向其自身 PK 的 FK。
PK 兼 FK 只能发生在 1 对 1 关系的子表中。

Answer 4

仅当两个表具有一对一关系并且添加第二个表是因为第一个表太宽且大多数查询中并不总是需要这些项目时，FK 才应该是 PK。

如果你有一对多关系或多对多关系，它根本不起作用。

FK 通常不是 PK。如果我有一个人员表和一个相关的地址表，如果我将 PK 和 FK 设置为同一对象，那么我只能存储一个地址，但大多数地址表允许同一个人或组织存储多个地址。在这种情况下，您将使用 AddressID 作为 PK，并使用 person_id 作为 person 表的 FK。这是最常见的 PK/FK 场景。

Answer 5

给定列既是 PK 又是 FK 的一种情况是 gen-spec 设计模式的关系模型。在其他响应之一中，“Employees”是“Persons”的特化。employees 表中的 PK 引用 Persons 表中的 PK。因此，专用表中的 PK 也是一个 FK。

这允许创建一个视图将员工和个人结合起来，在一个视图中提供有关员工的所有数据，无论该数据是员工特有的（如“雇用日期”）还是所有人共有的，无论他们是否是员工（如“出生日期”） )

使每个 PK 也成为 FK 并不是一个好的做法。如果逻辑模型不合逻辑，那么您就会遇到麻烦。