Mysql 将数据库逻辑放在应用程序中，而不是触发器、存储过程、约束等

我使用的是Rails，它不支持特定于数据库的操作，如触发器、存储过程和各种约束（并非所有约束）

我想知道是否应该将数据库逻辑放在应用程序本身中

因为这样，您可以创建比数据库提供的更复杂的逻辑，并且它也是独立于数据库的（我可以从mysql迁移到postgresql，反之亦然），如果您将这些东西放在数据库中，就不会这样了

走这条路对吗

---

大体上说，是的，主要是因为你刚才提到的原因

触发器尤其糟糕，因为当执行操作时，对于开发人员来说，它对于幕后实际发生的事情非常不透明。我倾向于将触发器的使用限制在审计功能上，或者限制在对保护系统数据完整性极其重要的功能上。我几乎完全避免在应用程序逻辑中使用触发器

存储过程也是如此。在这个ORM如此普及的时代，我使用存储过程进行大规模的、基于集合的数据修改，当使用诸如Rails之类的ORM时，这些修改的性能会非常糟糕，这要求您从数据库读取数据，并在处理完数据后将其封送回数据库层。

（注意：这是一篇以Postgres为中心的文章。我有几年使用MySQL的经验，还有一些Postgres和Oracle的经验。我更喜欢国家英里以外的Postgres，但这不是本文的重点。）

这实际上是一个关于两种思想流派的问题：数据库应该仅仅是一个数据存储还是应该包含应用程序逻辑？两者都有

在几个数据库（esp Postgres）在数据库本身中使用了一些非常非常好的过程语言之前，答案通常要简单得多。在这之前，在应用程序中尽可能地使用所有逻辑是有意义的，因为在基本SQL中完成一些事情需要相当困难

Dave Markle在另一个答案中对触发器提出了一个很好的观点，它们往往是“神奇的”对于开发人员来说，在输入的过程中更改输入可能会让人非常困惑。如果我说

UPDATE foo set X=3；

，然后我去检查

foo

，而

X

实际上是

4

，因为一些触发器截获了它，这可能会让人困惑。像Dave一样，我倾向于为审计函数等升级触发器。另一个是iss带有触发器的ue就是性能，它们可以从良好的批处理操作中吸取生命

存储过程——我更看重它。开发人员正在显式地调用它们并对它们进行命名，因此他不应该将它们视为一个黑匣子。一个好的存储过程可以通过减少需要“通过线路发送”的行数来大大提高速度.对于像Postgres这样拥有强大PL语言集的DB来说，SP中没有什么不可能的（这并不意味着应该这样做，但可以这样做）。请看一个存储过程如何成为您的朋友的示例。此外，您可以在应用程序代码与PL/python、PL/Perl或PL/Php、PL/Ruby或PL/Java之间共享应用程序逻辑类。我相信Oracle可以与Java做类似的事情—这不是我目前为Oracle工作的公司所做的事情与…打交道

如果您计划保持数据库不可知，那么您将牺牲大量的功能、速度和时间。ORMs可以使这变得更容易，但最终大多数数据库引擎都存在根本性的差异，无法完全抽象

总的来说，你需要测试、测试、测试（使用真实数据），并做出最适合你的应用的决定。这通常是性能、未来维护、成本和你必须使用的资源之间的平衡。通常是多次（不是每次），将逻辑移出数据库并移入应用程序，这会大大降低应用程序的性能

---

即使您没有决定将应用程序逻辑放在数据库中，也要花时间真正了解您所选择的数据库。从长远来看，这将使您成为一名更好的应用程序开发人员。

如果您已经在使用Ruby on Rails，那么您已经承诺使用固执己见的软件。Rails在这方面的观点是正确的还是错误的逻辑是在Rails应用程序中进行的。它甚至可以通过ActiveRecord及其关联强制实现引用完整性本身，当然，如果您愿意，您可以通过向表中添加约束来在数据库中强制实现引用完整性。许多Rails开发人员都不介意，无论是出于无知还是出于选择

• 当您开始偏离Rails的观点和惯例时，Rails提供的生产力收益往往会减少
• 如果您编写的应用程序能够处理大量数据，并且能够从利用特定的RDBMS功能中获益，那么无论如何，这对Rails来说都是不合适的，因为它是为创建新的CRUD web应用程序而优化的

因为这样，您可以创建比数据库提供的更复杂的逻辑，并且它也是独立于数据库的（我可以从mysql迁移到postgresql，反之亦然），如果您将这些东西放在数据库中，就不会这样了

逻辑取决于数据库-例如MySQL不支持递归查询，也不支持分析功能。PostgreSQL最近才得到分析-SQL Server从v2005开始就有了这两个功能；Oracle从9i开始就有了这两个功能

应用程序中的数据库逻辑通常意味着应用程序和数据库之间有更多的行程-这是您永远无法收回的时间/性能。数据库行程非常昂贵，而且要尽可能少-这就是为什么存储过程和函数是实现高可伸缩、高性能持久层的最佳工具

奥姆有

 Database Trigger
   pros:
     - Simplifies application logic
     - Better performance
   cons:
     - Maintaince is harder
     - Database dependency
     - Batch operation performance problems
     - If you don't have access to database for prod envoriment, It can be harder to manage


 Application Logic:
   pros:
     - Maintaince can be done in one place. It is good thing.
     - Database independent if you use ORM tools or frameworks.
   cons:
     - Performance may be problem
     - Add some complexity to the application logic