数据库中的业务逻辑是否在家？

不，这不是一个玩笑的帖子。请耐心等待，我将解释在什么情况下将数字运算业务逻辑从Oracle，IBM DB2，MSSQL Server和MySQL存储过程中移动到可伸缩的应用程序级别是有意义的。

在我看来，这些是业务逻辑最好在应用层实现的三个主要原因。进一步的原因可以在综合博客中找到，存储过程是EVIL，由Tony Marston编写。

可扩展性和性能

如果所有业务逻辑都以存储过程的形式在数据库中执行，那么数据库就成了瓶颈。一旦负载开始增加，性能就会相应降低。单个存储过程的执行可能比使用应用程序代码执行等效逻辑更快。但是，由于存储过程在数据库服务器上执行，因此应用程序将受到数据库服务器处理能力的限制。

解决方法是使用水平扩展并物理地分离处理任务，其中从数据库任务中体验性能降低。这允许独立于数据层优雅地缩放应用层。由Hibernate或Oracle TopLink等工具实现的对象关系映射（ORM）层可用作关系数据和对象应用程序层之间的粘合剂。这篇文章解释了Web 2.0的横向扩展。

也可以使用垂直缩放，但这更复杂，成本更高。这是一个短期解决方案，类似于在不解决根本原因的情况下简单地在问题上投入更大的马力。

供应商锁定

许多大公司不预测变化，对外部力量的反应非常缓慢。在查看IT基础架构时尤其明显。30到40年前，公司仍在使用遗留系统，主要是因为他们正遭受供应商锁定。这是数据库的一个特殊问题，因为每个供应商都有自己专有的存储过程语言和功能。例如，Oracle 11g PL / SQL和MSSQL Server T-SQL。

如果您为单个公司构建和维护数据库，您可能会认为这不是问题，数据库供应商的更改需要数年才能实现。但是当你的数据库突然不是本月的风格而管理层要求改变时会发生什么呢？这可能是因为各种因素，例如螺旋式成本或性能不佳。当它发生时，你会发现会有大量的代码需要重写。迁移数据是一回事，但移植存储过程，函数和触发器是一个更大的故事！

现在，如果所有逻辑都保存在应用程序中，那么想象一下在数据库供应商生态学中移动的简单程度，允许根据您当前的需求选择最佳数据库，而不是10 - 20年前的需求。

维护梦魇

存储过程本身形成API。应避免更改API，因为它需要更新使用它的客户端代码。这意味着开发时间和金钱。通常，当表或存储过程的行为发生更改时，会添加新的存储过程。一开始，这听起来不像是一个问题。但是，当您处理30年前的大规模遗留系统时，您最终会得到的东西只能被描述为涉及数百万行代码的程序的意大利面结合。实际上，代码库成为开发人员使用的泥潭，导致性能，可维护性和可扩展性不断降低。这直接影响了业务成本。