4

我问的原因是我们想使用 MySQL 目前不支持的某个 CHECK 约束。如果没有这种类型的约束,使用外键和引用完整性的全部原因似乎会随着应用程序代码承担更多的数据库责任而减少。

如果我们要创建一个“哑”数据模型并将所有引用完整性检查移动到应用程序代码中的一个层,那么潜在的测试可能会更简单,因为引用完整性错误将被捕获在应用程序而不是数据库中。它还可以潜在地加速新模块的开发,因为它们在测试之前不一定必须是引用完整的(这是一个术语吗?)。

那么,在 MySQL 中坚持使用“正确”数据模型并保留外键和“ON UPDATE CASCADE”语句等还有其他好处吗?

或者,我们应该抛弃 MySQL 并转向别的东西吗?!

谢谢!

4

3 回答 3

7

一些开发人员主张在数据库中根本没有业务逻辑——你的愚蠢数据存储。所以这绝对是一个有效的策略。

将约束(和其他业务逻辑)从数据库中移出让我担心的是,在所有地方强制执行约束更加困难。每个应用程序中的每个开发人员都可能违反该约束。DBA 也无能为力。

因此,我倾向于在数据库本身中包含这些规则。

于 2012-01-16T17:15:00.393 回答
2

您可以通过其他方式模拟检查约束

  • 扳机
  • FK 到单行表
  • 单值枚举

这很不方便,但不是世界末日。

无论如何,并非所有约束都可以或应该在应用程序中完成。独特性?零和检查(例如,账户停用前余额 = 零)。

这是你的数据和你的烂摊子,当它出错时要清理......

于 2012-01-16T20:58:43.423 回答
0

是的,如果您需要 MySQL 不支持的功能,那么您应该转向其他东西。

于 2012-01-16T17:13:12.937 回答