使用 MySQL 除了作为“哑”数据库之外还有什么好处吗？数据存储？
我问的原因是我们想使用 MySQL 目前不支持的某种 CHECK 约束。如果没有这种类型的约束，随着应用程序代码承担更多数据库的职责，使用外键和引用完整性的全部理由似乎就会消失。
如果我们要创建一个“哑”数据模型并将所有引用完整性检查移至应用程序代码中的一层，那么潜在的测试可能会更简单，因为引用完整性错误将被捕获在应用程序中而不是数据库中。它还可能加速新模块的开发，因为它们在测试之前不一定必须参考完整（这是一个术语吗？）。
那么，在 MySQL 中坚持使用“正确的”数据模型并保留外键和“ON UPDATE CASCADE”语句等还有其他好处吗？
或者，我们应该放弃 MySQL 并转向其他东西吗？！
谢谢！
The reason I ask is that we'd like to use a certain CHECK constraint which MySQL currently doesn't suport. Without this type of constraint in place, the whole reason for using foreign keys and referential integrity seems to diminish as the application code takes on more of the database's responsibilities.
If we were to create a 'dumb' data model and move all of the referential integrity checking to a layer in the application code, then potentially testing could be simpler as referential integrity errors would be trapped in the application rather than the db. It could also potentially speed up development of new modules, as they wouldn't necessarily have to be referentially complete (is that a term?) before testing.
So, are there any other benefits to sticking with a 'proper' data model in MySQL and keeping foreign keys and 'ON UPDATE CASCADE' statements, etc?
Or, should we ditch MySQL and move to something else?!
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一些开发人员主张数据库中根本没有业务逻辑——愚蠢的数据存储。所以这绝对是一个有效的策略。
将约束（和其他业务逻辑）移出数据库让我担心的是，在任何地方强制执行约束都更加困难。每个应用程序中的每个开发人员都可能违反该限制。 DBA 也无能为力。
因此，我倾向于在数据库本身中包含这些规则。
Some developers advocate having no business logic at all in the database -- your dumb data-store. So that is definitely a valid strategy.
What concerns me about moving the constraints (and other business logic) out of the database is that it is more difficult to enforce constraints everywhere. Every single developer in every single application can violate that constraint. The DBA can't help, either.
So, I lean toward having these rules in the database itself.
您可以通过其他方式模拟检查约束
很不方便，但不是世界末日。
无论如何，并非所有约束都可以或应该在应用程序中完成。独特性？零和检查（例如，账户停用前余额为零）。
当出现问题时，需要清理的是您的数据和混乱......
You can emulate a check constraint in other ways
It's inconvenient, but not the end of the world.
Not all constraints can or should be done in the application anyway. Uniqueness? Zero-sum checks (eg balance = zero before account is deactivated).
It's your data and your mess to clean up when it goes wrong...
是的，如果您需要 MySQL 不支持的功能，那么您应该转向其他功能。
Yes, if you need a feature that is not supported by MySQL then you chould move to something else.