我正在建立一个数据库,希望在其中一些表之间有多对多的关系。这个数据库没有用户界面;我们将使用r脚本将数据放入表中,并使用python脚本检索数据。
所涉及的实体是项目和成本预测。多个项目可能使用相同的预测。对于每一个预测,在未来几年中的每一年都有开发一个项目的成本。我需要能够检索每个项目的每个未来一年的成本预测。
我认为下表将是一个相当标准的方式来表示这些关系。请注意,“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
表与表之间有直接的多对多关系 PROJECT
以及 COST
,使用 forecast_id
? 我知道这在物理上是可能的,但是许多讨论使用的语言都是“没有桥表就不可能有多对多的关系”。但是如果我可以在没有桥表的情况下执行所有查询,并且还需要维护一个表,那么我为什么要添加桥表呢?
更进一步地说,许多关于多对多关系的讨论(包括下面@mike organek的评论)表明了一种类似于以下的结构:
PROJECT
project_id (pk)
name
PROJECT_COST
project_id (fk)
cost_id (fk)
COST
cost_id (pk)
year
cost
虽然这似乎是一种常见的首选方法,但它更不适合我的需要。现在每次我添加一个新项目,而不是仅仅分配 forecast_id
对应于一个特定的预测,我必须在project\u cost表中添加一堆链接记录,为未来的一年添加一个。这也需要大量的管理,并允许创建我不想要的潜在关系(例如,一个项目使用前两年一个预测的成本,然后使用未来两年不同预测的成本)。
所以我的第二个问题是,第二种方法是否优于第一种方法,或者优于我的简化方法(仅使用项目和成本表)?
更新
我问的问题似乎有些混乱。所以我对这个问题做了重大修改,试图让它更清楚。注意,我重命名了 cost_group
至 forecast
作为其中的一部分。
1条答案
按热度按时间uplii1fm1#
第二种方法(使用
project_cost
包含两个外键的表)是建模多对多关系的正确方法。但是你的想法
forecast_id
(带或不带)forecast
表)表明你没有考虑普通意义上的多对多关系:如果一个project
与一组特定的cost
s、 所有其他project
s必须与相同的或不相交的cost
s。如果这是你想要的,我认为移除
forecast
table。你不会因此而失去参照完整性。如果您有额外的要求,例如,必须至少有一个
cost
和一个project
对于每个现有的forecast_id
,事情可能会改变。这可以通过来自forecast
table,但不能没有那张table。