没有交集的多对多关系table？

Question

我正在建立一个数据库，我想在其中建立一些 table 之间的多对多关系。这个数据库没有用户界面；我们将使用 R 脚本将数据放入 table 并使用 Python 脚本检索数据。

涉及的实体是项目和成本预测。多个项目可能使用相同的预测。对于每个预测，未来几年的每一年都有开发项目的成本。我需要能够检索每个项目未来每一年的成本预测。

我认为下面的 table 是表示这些关系的相当标准的方式。请注意，“pk”表示“主键”，“fk”表示“外键”。

PROJECT
  name
  forecast_id (fk)

FORECAST
  forecast_id (pk)

COST
  forecast_id (fk)
  year
  cost

要检索特定项目的预测，我只需检索 COST 中具有匹配 forecast_id 的所有行。我不需要 FORECAST table 做任何事情，除了作为 forecast_id 的家，它在 PROJECT 和 COST 之间建立多对多关系].

所以我的主要问题是，我可以只删除 FORECAST table 并在 PROJECT 和 COST 之间建立直接的多对多关系，使用forecast_id？我知道这在物理上是可能的，但许多讨论都使用“没有桥梁 table 就不可能存在多对多关系”这样的语言。但是我为什么要添加桥 table，如果我可以在没有它的情况下完成我的所有查询，而且它又是一个 table 我必须维护？

更进一步，许多关于多对多关系的讨论（包括下面@mike-organek 的评论）提出了与此类似的结构：

PROJECT
  project_id (pk)
  name

PROJECT_COST
  project_id (fk)
  cost_id (fk)

COST
  cost_id (pk)
  year
  cost

虽然这似乎是一种普遍首选的方法，但它更不适合我的需要。现在每次我添加一个新项目，而不是仅仅分配对应于特定预测的 forecast_id，我必须添加一堆 link 记录到 PROJECT_COST table , 一个代表未来的每一年。这也将需要大量管理，并允许潜在地建立我不想要的关系（例如，一个项目在前两年使用来自一个预测的成本，然后在接下来的两年使用来自不同预测的成本）。

所以我的第二个问题是，与第一种方法或我的简化方法（仅使用 PROJECT 和 COST tables）相比，第二种方法有什么更好的地方吗？

更新

我在这里问的问题似乎有些混乱。因此，我对问题进行了重大修改，以使其更清楚。请注意，作为其中的一部分，我将 cost_group 重命名为 forecast。

Answer 1

第二种方法（project_cost table 包含两个外键）是建立多对多关系模型的正确方法。

但是您对共享 forecast_id（有或没有 forecast table）的想法表明您没有考虑普通意义上的多对多关系：如果一个 project 与特定的一组 cost 关联，则所有其他 project 必须与同一组或一组不相交的 cost 关联。

如果那是你想要的，我认为删除 forecast table 没有问题。这样你就失去了参照完整性。

如果您有其他要求，例如每个现有 forecast_id 必须至少有一个 cost 和一个 project，情况可能会有所不同。这可以通过外键 from 和 forecast table 来保证，但不是没有 table.

没有交集的多对多关系table？

Many-to-many relationship without intersection table?

sql

database

postgresql

database-design

database-normalization