我不确定如何提出这个问题,这可能是一个简单的答案。
我有两张这样的桌子。
Office
------
PK OficeId
OfficeName
Location
--------
PK LocationId
FK OfficeId
这样的一个表我存储相关信息。
PurchaseOrder
-------------
PK PurchaseOrderId
FK OfficeId
FK LocationId
因此,我的数据库将包含具有位置的主管局列表。这是一个办公室到多个地点。办公室可以是公司,也可以是公司。
因此,当我插入采购订单时,我想真正存储OfficeId,但OfficeId和LocationId必须是满足其他表中1对多关系的配置。我知道我可以简单地存储LocationId并加入查询中,我可能最终会这样做,但是想先问一些专家。
我正在使用SQL Server 2012.在没有创建触发器的情况下执行此操作是否有约束,只需检查它是否为有效配置?
答案 0 :(得分:1)
当您承认自己并且评论员指出时,PurchaseOrder表中的OfficeID是多余的,并且会对您的数据模型进行去标准化。除非你需要将它保留在那里,否则当你需要将办公室与PurchaseOrder相关联时,我会将其删除并进行适当的连接。外键和索引将有效地处理这个问题。
如果你真的想保留专栏并确保参考完整性,也许这就是你正在寻找的答案:Multiple-column foreign key in MySQL?
答案 1 :(得分:0)
多年来,我发现当“为了方便”做出任何建模决策时,最终都会出错。
在您的模型中,PurchaseOrder涉及与Office相关的位置。将PurchaseOrder直接缩短到Office的关系可能会有一段时间。然后,多年后,公司的一次小规模重组最终将德克萨斯州的办公地点从伊利诺伊州的MidWest办公室重新分配到新墨西哥州的西部办事处。
所以你(或你的前任)更新了Location表。但现在各种报告和查询都返回了错误的信息。也许结果很容易找到并解决问题,但为什么要首先让自己处于这种情况呢?
如果您想要方便,请使用一种不会因为数据更改而容易受到未来异常影响的方法。在这种情况下,使用正确的引用创建一个显示具有位置和Office的PurchaseOrders的视图。现在,当办公室发生变化时,视图将显示新办公室,并且基于视图的每个报告和查询都按预期工作。
视图非常适合这种用途。只是不要为了琐碎的目的而操纵底层模型。数据完整性建模的目标是数据完整性。对不起,但易用性在优先级列表的最底部是方式。