如何设计一个员工可以属于部门或部门的数据库

Posted 2023-03-08

【中文标题】如何设计一个员工可以属于部门或部门的数据库

【英文标题】：How to design a database where employee can belong to either department or division

【发布时间】：2010-12-04 23:28:51

【问题描述】：

我有一个存储员工、部门和部门的数据库。每个员工可以属于一个部门或部门（一对一关系）。为了存储这些数据，我创建了三个表：员工、部门、部门。如何正确连接它们以存储这种关系。

最简单的方法是在Employees表（department_id和division_id）中有两个可以为空的外键，但我想知道是否有更好的方法？

【参考方案1】：

不一定更好，但另一种方法是将部门和部门建模为更一般的实体“业务单位”的子类型，然后将员工与业务单位联系起来。

【讨论】：

这可能是我要走的路。问题：部门也属于部门吗？如果是这样，您需要在 BusinessUnits 表中使用自引用 FK。

【参考方案2】：

另一种答案：

如果您对部门和部门的两个表感到困惑，请将员工分配到一种业务单位并使用 ID 进行引用。

添加一个名为“assignment_type”的表，其中包含两条记录（今天）：部门、部门。

添加一个名为“employee_assignment”的表，其中包含三列：employee_id (fk)、d_id (fk)、assignment_type (fk)。

【参考方案3】：

由于您要与员工和部门打交道，我猜您不会一直批量加载大量此类数据行。基于这个假设，检索是最重要的。

由于有多种方法可以存储这些数据，因此您需要考虑需要哪些类型的查询来检索这些数据。您必须实施哪些类型的搜索、报告或数据加载。基于此，您应该查看存储数据的每种方式以及编写所需查询的性能和易用性。您如何添加索引等。存储数据的最酷方式可能最终会成为您需要的查询方式的主要痛苦。

【参考方案4】：

Tony 的业务部门方法是一种可行的方法，特别是如果集合 Devision,Department 在未来可能会增长。

另一种方法是使用两个外键方法，但包含一个检查约束，使得 Employee 表中的一列且只有一列是非 NULL。

您可以走更远的路线 - 例如如果 Department 和 Devision 表的主键域不相交但兼容，您可以在Employees 表中创建一个（一组）列，该列（取决于它们的值）是对部门或部门的引用，然后使用计算列作为外键约束的来源。

一切都是可行的，你必须选择你认为最自然的东西。