数据库:应用程序逻辑应该在哪里运行？

Question

http://highscalability.com/blog/2010/11/9/facebook-uses-non-stored-procedures-to-update-social-graphs.html谈到了Facebook如何将逻辑从数据库转移到应用程序中，以提高开发的易用性(更好地跨员工而不是跨数据库)。

是否有任何研究/文章/基准来评估运行数据库中的逻辑与应用程序中的逻辑的业务和技术权衡？

具体来说，我想知道什么样的规模更好(无论是在数据库性能方面，还是在业务发展过程中的易于开发方面)：

场景1(数据库中的逻辑)

• 在数据库端运行同样多的逻辑。
• 使用特定于数据库的SQL扩展/特性。
• 使用存储过程。
• 短事务查询少，网络开销低。

场景2(应用中的逻辑)

• 在应用程序端运行同样多的逻辑。
• 将自己限制在所有主要数据库中常见的特性上。
• 不使用存储过程。
• 许多查询涉及长事务，网络开销高。

在场景1中，什么样的人可以增加开销呢？

在场景2中，可能会出现什么样的数据库扩展开销？

Answer 1

回答我自己的问题(汇总我迄今所读到的所有内容)：

• 关注点分离--
  • 在应用程序中实现业务逻辑，以便在数据库之外提供受益于更丰富的开发、测试和调试环境。
  • 数据完整性和交叉关注点(例如审计、报告) 应该驻留在数据库中。。
  • 数据库需要一个抽象层。，以避免代码重复，并使您能够在模式更改时快速更新SQL语句。抽象层可以驻留在应用程序或数据库中。

• 性能
  • 准备好的语句与存储过程一样快。
  • 网络开销可以忽略不计，除非您需要将大量数据从服务器传输到客户端，然后再传输回来。.

• 安全
  • 存储过程与用于注入攻击的动态SQL相比，安全性不高.
  • 存储过程允许您根据API方法而不是表/视图级别授予权限。这意味着，您拥有的不是“只允许客户查看表Account和更新表Balance”，而是“只允许客户调用TransferFunds()”。您应该能够使用视图来模拟相同的权限方案。。

• 通用-用例
  • 如果数据库需要支持多个应用程序，抽象层应该以存储过程的形式驻留在数据库中。。这是DBA用于在数据库中实现逻辑的最多 频繁 被引 用例。
  • 如果应用程序需要支持多个数据库，请使用抽象层应该驻留在应用层中。。

• 杂项
  • 您的开发人员应该精通SQL。学习这种语言比你想象的要容易得多。不要自欺欺人:寻求避免SQL的开发人员会产生可伸缩性问题。

摘要:与流行的观点相反，您不应该出于性能或安全原因使用存储过程。您应该使用它们来支持多个应用程序，增强数据完整性，并实现无法在应用程序层中轻松实现的交叉关注点。

可以随意地将所有剩余的逻辑推入应用层。

Answer 2

可伸缩性不是做出这一选择的唯一问题(我确实知道有数万亿记录的成功数据库，因此数据库比您想象的更具有可伸缩性)。这也可能不是最重要的。

首先，您需要查看数据的含义。像Facebook这样的东西与它的应用程序有着内在的联系，因此逻辑上没有商业应用程序那么危险，商业应用程序必须从导入、数据库作业、来自几个不同应用程序的用户数据输入中获取数据，包括一些业务可能无法控制的应用程序。因此，在做出这种选择时，首先要考虑的是数据完整性的风险，也是最重要的考虑因素。

另外，数据将如何使用，以及在什么环境中至关重要。这些信息是如何审核的？是否有监管要求？报告是怎么做的？我需要能够在不同的报告系统以及用户应用程序中重用逻辑吗？如果是这样，则逻辑需要停在应用程序之外。我是否需要导出数据，以及如何受应用程序中的逻辑的影响。这是否意味着编写报告和导出代码的人将无法看到逻辑是什么，因为他们无法访问应用程序代码？这可能是个大问题。

另一个考虑因素是可伸缩性，其中包括性能。您需要多少可伸缩性？很少有东西需要Facebook的可伸缩性。你需要多少性能？当您永远不需要时，为可伸缩性而设计它会导致少于最佳结果。用于将逻辑放入应用程序中的方法会对数据库性能产生负面影响(例如，许多ORM编写糟糕的数据库代码)。

还有关于发展时间更少的争论，这是荒谬的。如果您知道自己在做什么，那么将逻辑放在数据库中并不比将逻辑放在应用程序中花费更多的时间。只是大多数应用程序开发人员不是SQL专家。然而，节省开发人员的时间以更好地掌握SQL真的是一个好处吗？不，这并不是因为这种选择几乎总是以牺牲数据库的性能和数据完整性为代价。

我想说的是，世界上没有一刀切的东西。有些应用程序将逻辑放入应用程序中是有意义的，而有些应用程序则没有，但是认为在做出选择时只需要考虑一两个关键因素通常是错误的。

Answer 3

好吧，有一个实际的答案，还有这个。

这个问题的标题是“应用程序逻辑应该在哪里运行？”但如果你想一想，这就把两件应该分开的东西混为一谈：

• 如何对应用程序逻辑进行编码？
• 应用程序逻辑应该在哪里运行？

当今数据库技术的一个大缺点是，对这两个问题中的任何一个作出选择通常会迫使你去解决另一个问题：

• 如果选择在数据库上运行应用程序逻辑，则必须使用数据库的过程语言(eeek，PL/SQL)，或者对第三方语言存储过程的支持非常繁琐。
• 如果您选择用一种好的编程语言编写应用程序逻辑，那么您将失去数据完整性的优势，除非您重复工作并在数据库中编写一些相同的逻辑。

但理想情况下，我应该能够用我选择的强大的编程语言编写一次我所有的应用程序逻辑，以及逻辑是在应用程序上运行还是在数据库上运行应该是一个后期的决定--这是我在部署应用程序时选择的，甚至是在运行时选择的。

实际上，理想情况下，我应该能够在浏览器、应用服务器和数据库中同时运行相同的逻辑。考虑一下表单驱动的web应用程序中的验证规则。理想情况下，您希望在所有三个层上运行验证逻辑：

1. 浏览器应该运行验证逻辑，因为当用户填写表单错误时，它可以向用户提供非常低的延迟反馈。此外，通过防止用户提交无效的表单，它减少了较低层的负载。
2. 应用服务器应该运行验证逻辑，因为它不能信任浏览器这样做--黑客可以绕过浏览器的逻辑。此外，通过在将无效表单发送到数据库之前捕获它们，它减少了该关键共享资源的负载。
3. 数据库应该运行验证逻辑，因为它负责为数据的多个用户执行数据完整性。

因此，您需要对逻辑进行一次编码，并拥有将其应用于所有三个地方的工具。但实现这一目标的技术却很少。