1

我有以下情况。我的桌子是：

表：公司员工

  • 员工ID
  • 出生日期
  • 加入日期

我还想存储每个员工的销售信息。我有这个：

表：已完成交易

  • ID
  • 员工ID
  • 交易名称
  • 交易金额

我的问题是——CompanyEmployees 中是否应该有一个名为“DealsCompletedID”的列直接引用 DealsCompleted 中的 ID 列，或者是否可以在两个 Employee ID 列之间创建一个外键？这是否对设计不利或可能扭曲规范化？

我不清楚关于我是否应该在 CompanyEmployees 中包含一个额外的列的规则是什么。

编辑请假设每个员工在交易表中只有一行。

4

2 回答 2

2

AFOREIGN KEY应该从一个表指向其在父表中的引用行，这两个表通常不应相互引用（两者都定义了外键）。

最FOREIGN KEY适合在DealsCompleted表中定义，它指向CompanyEmployees.EmployeeID。这样想 - 该CompanyEmployees表存储有关员工的信息。他们完成的交易并不能真正算作有关员工的信息。但是，完成交易的员工是交易信息的一部分，因此密钥属于那里。

拥有DealsCompleted.EmployeeID将允许员工和交易之间建立适当的一对多关系。也就是说，一名员工可以DealsCompleted根据需要拥有尽可能多的相关行。另一方面，在表中包含一DealsCompleted列将要求您复制有关员工的行，这会破坏规范化，或者在一个列中包含多个值，这也是不正确的。CompanyEmployeesDealCompletedID

上面编辑后更新即使您只计划建立一对一的关系（每个员工一个交易），仍然更适合引用EmployeeIDinDealsCompleted而不是其他方式（或两种方式）。...并且它允许您在需要时扩展到一对多。

于 2013-01-27T16:41:33.353 回答
1

正如您所说，假设关系始终是一对一的，那么答案取决于领域模型中的主要实体是什么。如果这个数据库的核心是一个关于 Deals 的数据库，而员工数据是辅助的，那么我会在 Deal 表中添加一个 EmployeeId FK 列。如果otoh，这是一个关于Employees的数据库，而Deals是辅助的，那么去掉Deal表中的EmployeeId列，在Employeee表中增加一个DealId FK列。

于 2013-01-27T16:57:36.670 回答