rah*_*286 8 mysql nosql foreign-key referential-integrity
我注意到 wordpress/rails 等不使用外键约束或从数据库中级联删除功能。相反，他们在 PHP/Ruby/脚本级别处理这个！
我已经阅读了这个和这个。大多数反对外键约束的论点都涉及性能、多线程、锁定、可伸缩性等。
假设反对外键的论点是有效的，我的问题是：
Tom*_*Tom 13
让我们从您的第一个链接开始。它说得很清楚：
在具有参照完整性的大型数据库上工作表现不佳。
这是正确的。只是您可能不知道“大型数据库”是 TB 级大小，表中有数十亿行。一个简单的选择可能会级联成数以亿计的相关元素被删除，然后就会出现性能问题。
对于常规的小型数据库（例如 wordpress 日志或大多数 CMS）而言，这不是问题 - 如果您执行诸如 facebook 之类的操作或处理金融模拟数据，它就会变成一个问题。我经常处理数十亿行表并删除在事务之外的存储过程中以 x 为批处理工作 - 因为最终删除可能很容易清理一些亿行。
他们会从 MySQL 转向 NoSQL 类型的服务器吗？
几乎不。当专业人员适当地使用它们时，它们会很有用。
另一方面，应用程序能否以某种方式编码以利用外键功能而不会遇到问题？
是的。
如果我们仅将数据库用于应用程序/脚本层的存储和管理“关系”，那么 noSQL/redis 会更好吗？
我曾经在一家不使用参照完整性的银行进行技术升级的应用程序审查（以提高性能）。将数据加载到 SQL Server（应该替换其老化的 Adabas 安装）中失败，并违反完整性约束。碰巧 40% 的历史记录是无效的，因为某些*删除了不再使用的查找表值（例如旧客户分类代码，它被所有活动客户替换，而不是旧客户）。没有出现参照完整性警告。结果是一些人被解雇了，一个问题被困在了解决方法中，并且在上面构建了一个部分无用的数据仓库。
管理应用程序/脚本层的关系到此为止。错误会发生。数据很有价值，应用程序会发生变化。
大多数抱怨 SQL 级别功能的人会更倾向于阅读有关它们的书，并尝试理解它们，而不是抱怨。可悲的是，互联网上的许多建议都是由甚至拒绝阅读文档的人写的。总是要小心。大多数对 NoSql 的建议都强烈地基于无知。