在SQL中的多对多表中添加关系“类型”是不好的做法吗？

如何解决在SQL中的多对多表中添加关系“类型”是不好的做法吗？

我正在构建具有以下两个表的Postgres数据库：

项目（id，startDate等） 和 员工（id，姓名等）

我想跟踪员工添加到项目中的捐款类型。例如，员工1可能是项目1的“工程师”，而项目2的“经理”。我也不想限制员工可以为某个项目做出的贡献数量。因此，第一个员工既可以是单个项目的“工程师”又可以是“经理”。

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

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

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

解决方法

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

避免每种贡献类型创建一个表，因为这种表不具有可伸缩性和灵活性。即如果有一天您将拥有一种新的供款类型，那么使用第二个选项每次就需要

• 创建一个新表
• 编写新的表管理逻辑
• 进行了sw的新部署

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

但是，如果您想管理软件中的贡献类型（在第一个发行版中或将来），也许最好使用一张带有贡献类型anagraphics的表格。这取决于您的设计和要求

,

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

创建一个表来存储带有列的捐款：员工ID，项目ID，捐款类型ID（您可能希望在其中找到其他列，但是这三列的组合应该是唯一的）。请勿将贡献类型作为字符串存储在这样的表中，因为，正如您正确提到的那样，这可能会导致拼写错误。另一个原因是节省磁盘空间。带有少量捐助类型表的额外联接是要付出的代价。