我使用的是 Rails，它不支持特定于数据库的操作，例如触发器、存储过程和各种约束(并非全部)。
我想知道是否应该将数据库逻辑放在应用程序本身中。
因为这样你就可以创建比数据库提供的更复杂的逻辑，而且它也是独立于数据库的(我可以从 mysql 移动到 postgresql，反之亦然)，如果你把这些东西放在数据库中就不会了。
这是正确的方法吗？
谢谢
最佳答案
(注意:这是一篇以 Postgres 为中心的文章。我有多年的 MySQL 经验，以及一些 Postgres 和 Oracle。我更喜欢 Postgres，但这不是这篇文章的重点。)
这实际上是一个关于两种思想流派的问题:数据库应该只是一个数据存储还是应该包含应用程序逻辑？两种情况都有。
恕我直言，在几个数据库(尤其是 Postgres)在数据库本身中获得一些非常非常好的过程语言之前，答案过去要简单得多。在那之前，在应用程序中踢掉所有可能的逻辑是有意义的，因为用基本的 SQL 完成一些事情必须相当笨拙。
Dave Markle 在另一个答案中就触发器提出了一个很好的观点，它们对开发人员来说往往是“神奇的”。在输入的过程中更改输入可能会非常困惑。如果我说 UPDATE foo set X=3; 但是我去检查 foo 并且 x 真的是 4 因为一些触发器拦截了它，这可能会造成混淆。和 Dave 一样，我倾向于推广审计功能等的触发器。触发器的另一个问题是性能，它们可以直接从良好的批处理操作中吸取生命。
存储过程 - 我更看重它。开发人员明确地调用它们并命名它们，因此他不应该将它们视为黑盒。一个好的存储过程可以通过减少需要“通过网络发送”的行数来大大提高速度。对于像 Postgres 这样具有强大的 PL 语言集的数据库，SP 中确实没有什么不能做的(这并不意味着应该做，但可以做)。看看SimplyCity有关存储过程如何成为您的 friend 的示例。此外，您可以在应用程序代码和 PL/python、PL/Perl、PL/Php、PL/Ruby 或 PL/Java 之间共享应用程序逻辑类。我相信 Oracle 可以用 Java 做一些类似的事情——这不是我目前在 Oracle 工作的公司正在与之合作的东西。
如果您打算保持与数据库无关，您将牺牲很多功能、很多速度和很多时间。 ORM 可以使这更容易，但最终在大多数数据库引擎中存在无法完全抽象掉的根本差异。
总的来说，您需要测试、测试、再测试(使用真实数据)并做出最适合您的应用的决定。它通常是性能、 future 维护、成本和您必须使用的资源之间的平衡行为。 经常(不是每次)，将逻辑从数据库移到应用程序中会大大降低应用程序的性能。
即使您不决定将应用程序逻辑放入数据库中，也要花时间真正了解您选择的数据库。从长远来看，这将使您成为更好的应用程序开发人员。
关于mysql - 将数据库逻辑放在应用程序中，而不是触发器、存储过程、约束等，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3378686/