加强数据库完整性

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

不通过内部数据库工具强制执行数据库完整性，可以期望多少性能改进？

说实话，数据库中不存在外键约束，您不仅不会看到很多性能损失，而且还会看到性能增强。SQL Server查询优化器是围绕主键和外键以及其他类型的数据约束的概念构建的。如果这些措施到位并得到实施，优化器可以利用它们来获得更好的性能。这是一篇博客文章，其中有一个简单的示例将其展示出来。

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

而且这些都没有提到这样一个事实，即在数据库上可以更好地处理数据完整性，因为您只需创建一次即可，就像在代码中完成所有工作一样，对于多个应用程序，您可能必须多次创建它（除非您进行设计）您的数据访问层要仔细，并要求每个应用程序访问数据库都必须经过同一层）。

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

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

当您试图将数据完整性委托给应用程序代码时，请考虑“从现在到时间结束，访问此数据库的每个程序员和每个应用程序都必须每次都使其完全正确。”

几率是多少？

即使性能有所提高，与引用完整性和广义数据完整性的返回相比，也可以忽略不计。

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

性能提升并不是全部，尤其是在如此小的规模上。但是，当您发现自己的应用程序应该具有假定的外键关系时，事实证明它不是引用表中的主键，那么您将很少关心性能提高（如果有的话，我可以不再赘述）。

如果您正在做足够大的数据负载，通常会删除约束（外键，CHECK等）和索引，然后再重新启用/实现约束和索引。验证需要花费时间。假设您不能使用数据库特定的大容量加载语法（包括最小化日志记录）。

很难说期望性能会提高多少-每种情况都是唯一的（数据类型，设计等）。真正了解的唯一方法是测试。

在某些情况下，约束会受到阻碍：

1. 需要使用单表继承（STI）时。想象一下，您既卖给个人也卖给组织。您将需要一个“ Party”表，该表的行可以是个人或组织。STI意味着您需要一些不可以为null的可为空的字段。类表继承解决了这个问题，但是对于某些ORM来说更难。例如，Ruby的ActiveRecord仅支持STI。

2. 当您需要支持实体的草稿版本时，这可能不是完全有效的。您可以将草稿存储为json，但是很难在客户端上重复使用相同的标识符-假设它已以id = 5保存，被编辑为无效并自动保存为draftid = 99。在这种情况下，您所有的字段都可能必须为空。