时间戳

首页 > 解决方案 > 将关系“类型”添加到 SQL 中的多对多表是不好的做法吗？

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

问题描述

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

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

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

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

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

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

标签： postgresqldatabase-designrelationship

解决方案

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

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

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

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

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

推荐阅读