将关系“类型”添加到 SQL 中的多对多表中是不好的做法吗？ [复制]

Question

我正在构建一个包含以下两个表的 Postgres 数据库：

项目（id、startDate 等...） 和 员工（身份证、姓名等）

我想跟踪员工为项目添加的贡献类型。例如，员工 #1 可能是项目 1 的“工程师”和项目 2 的“经理”。我也不想限制员工可以为某个项目做出的贡献数量。因此，员工 #1 可以同时是单个项目的“工程师”和“经理”。

我的第一直觉是在两个名为 ProjectEmployees 或其他东西之间建立多对多关系，并将 projectId、employeeId 和 contributionType 存储为字符串，该字符串仅采用枚举中的值而不必处理有拼写错误或任何相关问题。

我的主要问题是这是否是一种不好的做法。我的另一个想法是将每种贡献类型拆分到自己的表格中。因此，不会有 EmployeeProjects 表，而是会有 ProjectEngineers、ProjectManagers 等表......并且不会将contributionType 存储为列，而是隐含在我正在使用的表中，并且该表只需存储项目 ID 和员工 ID。该数据库中有更多表具有类似的关系，其中不同表之间存在多对多关系，但每个关系都可能是许多“类型”关系中的一种。将这些全部拆分为每种关系类型的单独表是否更明智？还是像我的第一个想法那样在更通用的表中跟踪关系类型更好？

我想要的结果是能够有效地查看员工从事的所有项目贡献（和类型），以及查看项目的所有贡献者 + 贡献者类型。

Answer 1

在您的第一个想法中使用多对多关系，我认为这是一种很好的做法。

避免为每种贡献类型创建一个表，因为它不可扩展且不灵活。 IE。如果有一天你会有一种新的贡献类型，那么你每次都需要第二个选项

• 创建新表
• 编写新的表管理逻辑
• 继续部署您的软件

关于将贡献类型存储在表上（带有 id 和描述）或作为枚举贡献类型字符串的约束的主题，在我看来，两者都是有价值的解决方案。

但是，如果您想在您的软件中管理贡献类型（在第一个版本中或将来），也许有一个包含贡献类型的表格会更好。这取决于您的设计和要求

Answer 2

制作一个表格，将贡献类型存储为字符串（经理、工程师等）和贡献类型 ID（数字 ID）。这样可以防止拼写错误。

创建一个表格来存储贡献的列：员工 ID、项目 ID、贡献类型 ID（您可能希望在其中添加其他列，但在这 3 列的组合中它应该是唯一的）。不要将贡献类型存储为这样的表中的字符串，因为正如您正确提到的，这可能会导致拼写错误。另一个原因是节省磁盘空间。额外加入一个包含贡献类型的小表的代价很小。