【问题标题】:Should my RDBMS or my Application handle database Referential Integrity?我的 RDBMS 或我的应用程序应该处理数据库参照完整性吗?
【发布时间】:2011-04-23 01:49:29
【问题描述】:

是否应该由数据库管理系统(在本例中为 MS Sql 2005)或应用程序处理外键、约束、默认值等项目?我听取了双方的意见,老实说,我不确定该走哪条路。

我最初打算将它构建到数据库中,但是我发现这并不总是可以用我当前的数据库设计来实现。例如,某些表包含循环引用,无法使用ON UPDATE CASCADE 链接。我遇到的另一个问题是我们可能会使用多个数据库/服务器,并且外键约束不适用于链接的服务器。

我有一些开发人员建议我在应用程序层上进行数据验证,并让数据库保持原样 - 一个存储数据的地方。我喜欢这个想法,但我在很多地方都读到过,最好将参照完整性构建到数据库中,以允许不通过应用程序层传递的事务。我同意这一点,尽管当我们完成时,所有数据库事务都应该通过应用程序。即使我们决定稍后构建插件,我们也使用 ObjectModel 框架,因此插入/更新/删除查询永远不需要重写。

所以我的问题是,在这种情况下,您是否仍然建议将参照完整性构建到数据库中,还是可以将其构建到应用程序层中?为什么?

【问题讨论】:

    标签: database referential-integrity


    【解决方案1】:

    可以的时候数据库管理系统,不能的时候应用程序。您希望在尽可能远的技术上实施,以便在其之上构建的任何东西都可以利用它。

    【讨论】:

      【解决方案2】:

      您应该在数据库中进行尽可能多的数据完整性维护。一旦您声明它就是“免费”的,并且保证应用无论数据如何到达数据库。对我来说,这似乎很简单。

      您提出了几个无法在数据库中以声明方式指定的数据库完整性类型的实例。在这些情况下,显然,您必须将完整性编程到中间层或前端,并希望获得最好的结果。

      【讨论】:

      • 它并不是真正的“免费”。由于数据库必须确保 RI,因此在插入、删除和更新过程中会产生一些性能成本。
      【解决方案3】:

      使用数据库做它最擅长的事情。包括参照完整性 - 它内置在数据库中并确保您的数据处于一致状态。

      如果这不适合您应用程序中的特定内容,请在您的应用程序逻辑/域模型中围绕它进行构建。

      就个人而言,如果可能的话,我会确保为应用程序和数据库添加引用逻辑(深度防御)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-03-21
        • 1970-01-01
        • 2012-06-08
        相关资源
        最近更新 更多