Question

我对数据库设计感到困惑。我是其中一家公司的开发人员，我和我的老板就数据库设计中的以下问题进行了讨论。我必须处理的数据库设计的一部分包含两个表：

Employees Table: Username, Name, JobTitle, OrganizationCode
Organizations Table: OrganizationCode, Name...

这两张表将照顾公司的所有员工，部门，部门和单位。其他开发人员设计的大多数数据库都是以这样的方式设计的，这两个表之间没有任何关系。

对我来说，我告诉我的老板，最好在这两个表之间建立关系（这意味着OrganizationCode是组织表主键的外键）。因为它很容易强制执行约束，完整性以及编写查询。

他没有给我正确的理由就拒绝了。我们的部门拥有2000多名员工，公司员工人数超过50000人。所以我认为他推荐的设计会占用很大的空间，从应用程序开发的角度来看很难处理。

你推荐什么人？

Answer 1

您和您的老板都需要了解分析和设计之间的区别。两个表之间关系的设计从属于现实世界中的主题，以及对数据库的信息要求。

当您从数据角度分析主题（所谓的“真实世界”）时，您将整个主题空间划分为这些实体之间的实体和关系。然后，将每个值作为属性的实例存储在数据库中。每个属性描述实体或关系的某些方面。每个属性还有一个域，该域是该属性的可能值集。所有这些构成了概念数据模型，并且发现了它的特征，而不是发明的。

然后，当您进行数据库设计时，可以根据您对实体，关系和属性的了解来设计列，表和外键。在给出概念模型和其他一些细节的情况下，您当然需要知道如何制作出好的设计。

那么，在你的情况下，这个项目是什么样的？员工在部门工作吗？那是一种关系。一个部门可以有很多员工在其中工作。员工可以在多个部门工作吗？如果是，那么你就有了多对多的关系。如果是这种情况，您将需要一个包含两个外键的联结表。如果没有，那么您的设计将充分反映多对一关系。

通过这种方式表达问题，就主题而言，您可以与老板就现实世界的结构达成共识。然后，您可以就外键如何帮助代表现实达成共识。或者你的老板可能满足于将数据库（重新）设计留给你，只要他/她保留对概念模型的否决权。

Answer 2

员工必须以某种方式与组织单位建立联系，问题在于是否保留该关系的历史。如果您不需要保留历史记录，那么您可以使用employee表中的组织代码，否则您需要组织和员工之间的联接表来显示员工 - 部门关系的历史记录。

另一个考虑因素是是否要保留组织间关系的历史记录，这需要另一个连接表。

Answer 3

你的设计比老板的设计要好。通过老板的设计，员工可以链接到不存在的组织单位。更新组织信息也很麻烦，这些更新必须在两个地方进行。

在当前时代，空间不再是一个重要因素，但系统的可维护性和确保数据正确应该是在两个表之间建立适当关系的决定性因素。

如果我是你，我会询问为什么你的老板反对强制执行这种关系。