数据库设计 - 外键与主键相同？答案

【问题标题】：Database Design - foreign key same as primary key?数据库设计 - 外键与主键相同？
【发布时间】：2012-11-04 21:36:56
【问题描述】：

我想如果这个简单的数据库建模没问题。特别是帐单表。各位能不能给点意见？

【问题讨论】：

除非你的外文是唯一的，但你必须检查 i=on indexing 问题
是的，但它可以不止一张桌子。我的问题是这个模型中是否有任何问题，因为我在 EmployeeProject 中的主键也是外键，并且在 Billing 中也是如此

标签： database ms-access database-design

【解决方案1】：

我想您是在问 EmployeeProject 中的主键是否可以由两个外键组成。如果我正确理解了您的问题，那很好。

在 Billing 中，外键由两个引用 EmployeeProject 的列组成，这并没有错。（在 SQL 中，foreign key (empNo, projectNo) references EmployeeProject (empNo, projectNo)。）您几乎可以肯定不需要两个单独的外键在此处引用 Employee 和 Project。

Billing 中的三列主键（SQL，primary key (billingNo, empNo, projectNo)）允许这样的数据。

billingNo  empNo  projectNo  hoursBilled
--
1003       13     7          3
1003       13     6          2
1003       17     7          8
1004       13     7          3
1004       13     6          2

如果这是你的意图，那么你就朝着正确的方向前进。

【讨论】：

谢谢伙计。如果我想在 Billing 中只拥有一个寄存器，我将不得不删除 billing 不对吗？
如果您希望 empNo 和 projectNo 的每个组合只有一行，您可以从 PK 中删除 billingNo。
您是否建议将此表中的所有 PK 都编入索引 - 不重复？
如果你问是否应该分别索引主键中的三列，可能不是。但是，如果您确实除了主键约束之外需要在三列中的每一列上都需要单独的索引，那么这些单独的索引将有允许重复.

【解决方案2】：

将外键列作为表的主键的一部分是完全可以接受的。例如，这在实现多对多关系的交集表中经常发生。

有些人发现最好使用代理键而不是复合键。当您使用外键列作为主键时，您几乎总是会使用复合键，而这些可能会变得庞大而复杂。

如果您在 StackOverflow 和其他地方搜索，您会发现关于自然键与复合键与代理键的相对优点的广泛而热情的讨论。如果您阅读这些内容，您会发现有很多人会支持您在模型中定义主键的方式。

【讨论】：