我对数据库设计感到困惑。我在其中一家公司担任开发人员，我与老板讨论了数据库设计中的以下问题。我必须处理的数据库设计的一部分包含两个表：
Employees Table: Username, Name, JobTitle, OrganizationCode
Organizations Table: OrganizationCode, Name...
这两张表将照顾公司中所有的员工、部门、部门和单位。其他开发人员设计的大多数数据库都是这样设计的，这两个表之间没有关系。
对我来说，我告诉我的老板最好在这两个表之间建立关系（这意味着它OrganizationCode是 Organizations 表主键的外键）。因为执行约束、完整性以及编写查询将很容易。
他拒绝了，没有给我一个正当的理由。我们部门有 2000 多名员工，公司约有 50000 多名员工。所以我认为他推荐的设计会占用很大的空间，从应用程序开发的角度来看会很难处理。
大家有什么推荐的吗？
你和你的老板都需要了解分析和设计之间的区别。两个表之间的关系设计服从于现实世界中主题的实际情况，以及对数据库的信息需求。
当您从数据角度分析主题（所谓的“现实世界”）时，您将整个主题空间划分为实体以及这些实体之间的关系。然后，您将要存储在数据库中的每个值视为属性的实例。每个属性都描述了实体或关系的某些方面。每个属性也有一个域，它是该属性的可能值的集合。所有这些构成了一个概念数据模型，其特征是被发现的，而不是发明的。
然后，当您进行数据库设计时，根据您对实体、关系和属性的了解来设计列、表和外键。给定概念模型和其他一些细节，您当然需要知道如何做出好的设计。
那么，就您而言，主题是什么样的？员工是否在一个部门工作？那是一种关系。一个部门可以有许多员工在其中工作。一名员工可以在多个部门工作吗？如果是，那么你有一个多对多的关系。如果是这种情况，您将需要一个包含两个外键的联结表。如果不是，那么您的设计将充分反映多对一的关系。
通过这种方式表达问题，就主题而言，您可能能够与您的老板就现实世界的结构达成共识。然后，您可能能够就外键如何帮助表示该现实达成共识。或者你的老板可能会满足于将数据库（重新）设计留给你，只要她/他保留对概念模型的否决权。
员工必须以某种方式与组织单位建立联系，而真正的问题是是否保留这种关系的历史。如果您不需要保留历史记录，那么您可以在员工表中使用组织代码，否则您需要组织和员工之间的连接表来显示员工-部门关系的历史记录。
另一个考虑是是否保留组织间关系的历史，这将需要另一个连接表。
你的设计比你老板的好。有了你老板的设计，员工就有可能与不存在的组织单位联系起来。更新组织信息也很痛苦，这些更新必须在两个位置进行。
在当今时代，空间已经不再是一个重要因素，但系统的可维护性和确保数据正确应该是在两个表之间建立适当关系的决定因素。
如果我是你，我会询问你的老板究竟为什么反对加强这种关系。