Rac*_*hel 1 database referential-integrity
外键,约束,默认值等项目是否应由数据库管理系统(在本例中为MS Sql 2005)或应用程序处理？我听过双方的意见,老实说我不确定要走哪条路.
我原本打算将它构建到数据库中,但是我发现使用当前的数据库设计并不总是这样.例如,某些表包含循环引用,无法使用链接ON UPDATE CASCADE.我遇到的另一个问题是我们可能会使用多个数据库/服务器,并且外键约束在链接服务器上不起作用.
我有一些开发人员建议我在应用程序层进行数据验证,并将数据库保留为存储数据的地方.我喜欢这个想法,但我已经在很多地方读过,最好在数据库中建立参照完整性,以允许不通过应用层传递的事务.我同意这一点,虽然当我们完成所有数据库事务时应该通过应用程序.即使我们决定稍后构建插件,我们也在使用ObjectModel框架,因此永远不需要重写插入/更新/删除查询.
所以我的问题是,在这种情况下,你仍然建议在数据库中构建引用完整性,还是可以将它构建到应用程序层中？为什么？
您应该在数据库中尽可能多地进行数据完整性维护.一旦声明它就会"免费",并且无论数据如何到达数据库,都可以保证适用.对我来说,这似乎是一个明智的选择.
您提出了几个无法在数据库中以声明方式指定的数据库完整性类型的实例.在这些情况下,显然,您必须将完整性编程到中间层或前端,并希望最好.
使用数据库发挥其最大作用。包括引用完整性 - 它内置于数据库中并确保您的数据处于一致状态。
如果这不适合您的应用程序中的特定内容，请在您的应用程序逻辑/域模型中围绕它进行构建。
就我个人而言，如果可能的话，我会确保向应用程序和数据库添加引用逻辑（深度防御）。