【问题标题】:How to establish foreign key relationship如何建立外键关系
【发布时间】:2015-04-15 06:33:23
【问题描述】:

我有三张桌子。

User
Project
WorkFlow

在工作流 ProjectId 中,UserId 不应一起重复。那是我的 要求。我的意思是这种组合永远不应该重复。

并且 ProjectId 应该存在于 Project 表和 UserId 中 应该存在于 User 表中。

这是要求。

我尝试过的步骤:

我将ProjectId, UserId 设为workFlow 中的复合键。但是不能维护外键,因为单个表中没有两列。

如何解决这个问题。

我也愿意改变我的设计,因为这是我发展的初始阶段。

主要要求是

一个表存储项目(项目表)相关信息和 另一个(工作流)保存项目分配到的记录 哪个用户。

【问题讨论】:

  • 您还可以使用 UNIQUE KEY CONSTRAINT 或 UNIQUE(集群或非集群)索引来强制非 PK 列的唯一性?
  • @StuartLC 那么可以删除复合键并使这两列成为唯一键吗?
  • 是的,就像下面@Roger 的回答 (+1),尽管建议您将 UKC 命名为。
  • @StuartLC,我都是手写的,所以尽量简短。在实际实践中,一些 CASE 工具通常非常有用,还有一些约束重命名脚本。

标签: sql sql-server database relational-database


【解决方案1】:

外键不控制唯一性;它们只控制参照完整性。为了唯一性,您需要唯一的约束:

create table dbo.Workflow (
    Id int identity(1,1) primary key,
    ProjectId int not null,
    UserId int not null,
    foreign key (ProjectId) references dbo.Project (Id),
    foreign key (UserId) references dbo.[User] (Id),
    unique (UserId, ProjectId)
);

编辑:如果您不需要此表中的代理键,并且不太关心其可能的子项,您可以通过从代理主键切换到自然主键来简化结构一。随着表变得越来越窄,它将通过减少磁盘占用来提高高负载场景下的性能:

create table dbo.Workflow (
    ProjectId int not null,
    UserId int not null,
    primary key (UserId, ProjectId)
    foreign key (ProjectId) references dbo.Project (Id),
    foreign key (UserId) references dbo.[User] (Id),
);

是的,约束应该被唯一命名,这将使模式比较和更新更加容易。

【讨论】:

  • 您好,感谢您的回复。是的,外键不会产生唯一性,我只需要它来实现参照完整性。好的,我会将它们更改为唯一键
  • 答案大部分是正确的,但有一个错误,新人使用关联表。这里id 字段和索引完全是多余的,没有任何作用。它是 PK 的概念是用id 字段标记每个文件并将其声明为“PK”的结果,这是完全错误的。删除 id 字段和索引。然后将(UserId, ProjectId) 设为主键。因为它是。
  • @PerformanceDBA,通常你是对的。然而,从主题领域来看,我认为 OP 很可能在这个下面有一些表格。而且由于大多数人在理解多列外键方面存在问题,因此我决定添加代理 PK。如果我的猜测是正确的,它还将解决“移动”问题(切换到另一个项目/用户),否则会导致 PK 更新并需要on update cascade,这通常是不可取的。但是,是的,这只是一个猜测。
  • @Roger Wolf。 (新观点,回应你的观点,我之前的观点成立。)好吧,如果 Workflow 有子表,并且 FK 是 id 的 Workflow PD,那么它将有任何没有完整性。他们需要与Workflow.ProjectId,Workflow.UserId 保持完整性,而不是Workflow.id. 这正是Workflow PK 应该是(ProjectId,Workflow.UserId. 的原因
  • @PerformanceDBA,看起来更像是“自然与替代”的辩论。如果您在子表中需要这些 Id - 很好,将它们进一步传播到链中。问题是,当您的主键为 5-6 列宽时(我见过更宽的,但那是一个合并仓库),整个方法开始变得可疑。不是最方便使用的结构,此外,它们会使表格膨胀太多,这会降低 OLTP 场景中的性能。
猜你喜欢
  • 2022-01-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-01-18
  • 1970-01-01
相关资源
最近更新 更多