强制执行数据库完整性

Ren*_*ovs 19 database-design sql-server

让应用程序强制执行数据库完整性而不是使用外键、检查约束等是否有意义?

如果不通过内部数据库工具强制执行数据库完整性,可以期待多大的性能改进?

Gra*_*hey 25

说实话,您不仅不会因为数据库中的外键约束而看到太多的性能损失,而且您会看到性能增强。SQL Server 查询优化器是围绕主键和外键的概念以及其他类型的数据约束构建的。如果这些都到位并强制执行,优化器可以利用它们来获得更好的性能。这是一篇博客文章,其中有一个简单的例子,展示了它的实际效果。

如果您处于插入比读取更多的边缘情况(并且更新和删除需要读取,因此它们通常最终会增加读取计数),那么从数据中删除约束以提高性能可能是有意义的,也许. 但是由于绝大多数数据库都是面向读取的,因此您正在牺牲性能,而不是增强性能。

并且这些都没有提到在数据库中更好地处理数据完整性的事实,因为您只需创建一次,就好像您在代码中完成所有工作一样,您可能必须为多个应用程序多次执行(除非您设计仔细检查您的数据访问层,并要求每个应用程序访问数据库以通过同一层)。

如果您使用的是关系数据库系统,我说,为什么不真正使用它。如果您不需要关系数据,请使用 Hadoop 或其他东西。

  • 这几乎与我的想法和预期一致。我知道我之前工作的 DBA 是错误的,只是想就此获得独立的意见。谢谢! (2认同)

Mik*_*ll' 17

许多应用程序开发人员都这么认为。

当您想将数据完整性委托给应用程序代码时,请想一想“从现在到时间结束访问该数据库的每个程序员和每个应用程序都必须每次都完全正确。”

赔率是多少?

  • +1。基本上就是这样。你用大量程序员必须遵守的要求替换了一个经过良好测试的中央系统。每次。不会发生 - 所以随着时间的推移,你会得到包含错误数据的数据库。 (5认同)

Tho*_*ger 13

即使有任何性能提升,与参照完整性和广义数据完整性的回报相比,也是微不足道的。

数据库是一个愚蠢的数据存储的日子已经一去不复返了。利用 RDBMS 提供的功能。

性能提升并不是一切,尤其是在如此小的规模上。但是,当您发现您的应用程序应该强制执行一个假设的外键关系时,结果证明它不是引用表中的主键,那么您将很少关心性能提升(如果有的话,我可以不谈具体情况)。

  • @TomTom 在您的应用程序中重写数据完整性逻辑正在重做已经在 RDBMS 中完成的工作。将数据逻辑保存在数据库中。 (5认同)

OMG*_*ies 6

如果您正在执行足够大的数据加载,通常的做法是删除约束(外键、CHECK 等)和索引,然后重新启用/实现约束和索引。该验证需要时间成本。那是假设您不能使用特定于数据库的批量加载语法(包括最小化日志记录)。

不可能说期望有多少性能提升 - 每种情况都是独一无二的(数据类型、设计等)。真正知道的唯一方法是测试。