【问题标题】:Relational database foreign key constraints usage in practice关系型数据库外键约束在实践中的使用
【发布时间】:2011-04-30 14:55:07
【问题描述】:

所以你有一个关系数据库,你定义了一些外键来保证引用的完整性。但是现在,利用它们的更好方法是什么?假设我们要删除一个表中的一行,其中包含指向其他表的外键。

  1. 将它们用作垃圾收集器 - 将所有约束设置为级联。因此,在您的应用程序中,您首先检查目标行是否有任何“子行”,如果不希望同时删除相关行,则向用户提供中止删除操作的选项。 p>

  2. 将它们用作实际的约束 - 在您的应用程序中,只需尝试删除目标行。如果操作失败,然后检查它是否有子节点并将选项呈现给用户;如果用户想继续操作,请先手动删除依赖行。

第二个选项使删除循环引用变得相当困难 - 您必须先将外键设置为 null,然后才能删除任何内容。

【问题讨论】:

    标签: foreign-keys relational-database


    【解决方案1】:

    有两种典型的外键场景:

    • 关联:链接 2 个可以单独存在的实体
    • 组合:将子实体链接到其父实体(子实体是否存在而没有父实体,例如:订单和订单商品)

    我只会在组合的情况下级联并单独处理每个关联情况。

    【讨论】:

    • 我认为您回答了错误的问题,或者我可能误解了您的答案......但我的困境适用于您的情况both。我的问题是应该执行完整性——而不是它是否应该被执行。在这两种情况下,一行依赖于另一行;问题是,删除时,谁来检查 - 数据库还是应用程序?
    • 我会依靠数据库来处理组合级联删除,因为在删除父母的同时保留孩子是没有意义的。对于关联,逻辑更复杂,取决于您的业务规则在哪里。如果它们在数据库之外,那么业务层(应用程序、服务)应该负责级联删除。但这种情况没有黄金法则。当您删除与部门关联的最后一个员工时,您是否删除了该部门?也许,也许不是,这取决于......
    • 我不是在寻找黄金法则;我想听听其他人在 practice 中的做法。不过,感谢您的意见。
    • 不客气,希望您能得到比我更多的反馈。
    猜你喜欢
    • 2016-06-30
    • 2016-10-14
    • 2020-03-17
    • 1970-01-01
    • 2015-05-17
    • 1970-01-01
    • 2013-12-17
    • 2018-01-23
    • 1970-01-01
    相关资源
    最近更新 更多