无限制运行数据库

Question

我们正在考虑为 OLAP 和 OLTP 场景使用新的专有高性能数据库引擎。目前它的一个重要方面是它不支持外键或其他约束。对于是否应将此限制视为 OLTP 应用程序的非启动器，您有何看法？

考虑对任何插入、更新和删除实施我们自己的参照完整性检查会不会很疯狂？

Answer 1

滚动您自己的参照完整性检查有以下缺点：

1. 速度 - 您自己的检查永远不会像数据库内部检查那样快。
2. 完整性 - 当你自己动手时，总是有可能会错过一些东西。

如果数据库引擎的高性能可以弥补损失，速度问题是可以接受的，但使用您自己的检查可能会丢失数据完整性仍然是一个问题。

Answer 2

从这个系统开始，数据质量问题的成本是多少？这些成本是否超过了使用该系统而不是其他一些实际强制执行参照完整性的系统的好处？

不幸的是，有很多应用程序（特别是那些“数据库不可知”类型的应用程序）实现自己的约束，而不是依赖数据库来强制执行关系完整性。他们在确保他们生成的数据合理方面的成功程度大相径庭——有些人做得很好，有些人似乎创造了一个混杂的数据并将其称为数据。但所有这些都会至少创建一些无效数据。

鉴于此，问题就变成了无效数据将花费您多少时间来解开。例如，如果您试图跟踪证券的销售情况，任何与有效客户无关的交易都会产生必须跟踪的问题。另一方面，如果您试图跟踪内部项目的工时，如果个人工作的某些工时与有效项目无关，这可能只是令人讨厌。如果您要花费数千个工时来清理您生成的数据，那么使用约束的系统将更具成本效益。如果足够接近就足够了，那么实施您自己的约束可能就足够了。

Answer 3

好吧，带有 MyISAM 的 MySQL 没有 FK 约束，并且仍然在非常广泛的基础上使用，因此，如果您妥善保管数据并从应用程序中进行适当的异常处理，那么应该没问题。

当然，诸如约束之类的东西可以构成一个非常好的模式，并保证您的数据一致并且条目指向真实的行。DELETE/UPDATE 约束也是非常好的补充，但这些事情可以通过触发器来完成（如果支持）。

总而言之，FK 及其约束应该是常规数据库的一部分，但如果它们对性能确实有很大影响，我认为（！）如果应用程序能够正确插入和检索数据而不会损坏，则可以将它们放在一边数据。