我正在关注这家公司的数据库设计，并想知道他们设计的目的，即在一个表中存储关系而在另一个表中存储数据，为什么会这样做？
他们有这个，
而不是......
......或者这......（员工可以属于许多部门）
答案 0 :(得分：3)
这是一个链接表，或连接表，或交叉表..许多不同的名称。
您如何根据您的设计将员工分配到两个不同的部门？你不能。您只能将它们分配给一个。
通过他们的设计，他们可以通过创建具有员工ID和不同部门ID的多个记录，为多个部门分配相同的ID。
编辑：
您需要更具体地了解您的要求。你的第一个问题似乎是询问映射表的目的是什么。然后你改变了它，然后你再改变它......没有一个是有意义的。
现在看来你问的是更好的设计是什么，这是一个完全不同于你最初问的问题。请具体说明您想要回答的问题，以便我们不必猜测。
EDIT2：
重新阅读时，如果这是实际设计，那么没有..它不支持多个部门ID。除了一种情况外，这样的设计没什么意义。如果原始设计不包含部门，则允许他们在不修改原始EMPLOYEE_DATA表的情况下添加部门ID。
他们可能不想更新遗留代码以支持Employee ID，因此他们以这种方式添加它。
答案 1 :(得分：1)
如果员工可以在多个部门，那么您需要一个映射表，但我会像下面这样做：
EMPLOYEE
Id (PK)
First Name
Last Name
DEPARTMENT
Id (PK)
Name
EMPLOYEE_DEPARTMENT
EmployeeId_fk (PK)
DepartmentId_fk (PK)
Position
这将允许多个部门的多个职位。
答案 2 :(得分：1)
设计目的由业务规则决定 业务规则规定了实体（逻辑模型透视）/表（物理模型透视）设计。如果根据业务规则确定的要求构建，则任何设计都不是“坏”。然而，这些规则可能会随着时间的推移而发生变化 - 预见到这些变化以及构建以适应/面向未来的数据模型可以真正节省时间，精力并最终节省资金。
第一个和第三个示例相同 - 第三个示例有一个无关列（EMPLOYEE_DEPARTMENT.id）。 ORM不喜欢复合键，因此使用单个列代替。
第二个例子很好，如果：
第一个/第三个示例对于大多数实际情况更加真实，并且可以轻松定制以提供更多价值而不会产生重大影响（重写整个表格结构）。它使用最常被称为多对多关系的方式，允许许多员工与许多部门建立联系。
答案 3 :(得分：0)
如果员工可以是多个部门的成员，您就会这样做。对于后一个表，每个员工只能属于一个部门。
答案 4 :(得分：0)
这样做的唯一远程正当理由是实现扩展模型，其中标识唯一客户的主表不包括并非总是必需的客户的所有数据。相反，您使用核心员工数据创建一个核心表，并使用所有补充字段创建扩展表。我见过人们采用这种方法来避免创建包含很多很少需要的列的大型表。但是，根据我的经验，这通常是过早优化，我不推荐它。
与许多回复相比，所包含的模型不支持每个员工的多个部门 - 这不是一个多对多的映射方法。