业务逻辑:数据库与代码

Question

我是一个系统工程专业的学生，我所有的老师和朋友(实际上在这个领域工作)都说，最好在数据库中实现尽可能多的逻辑(查询、视图、触发器、T-SQL等等)。我觉得把它写在密码里比较好。

他们的理由是：

• 如果他们需要改变语言，几乎所有的逻辑都将在数据库中；因此，实现的时间将是最小的。
• 语言中的更改比数据库中的更改更常见。

我的理由是：

• 很明显(至少在我国目前的环境中)，它们不会改变“容易”的项目语言。(我已经看到了还在FoxPro中的程序，因为如果它能工作，就没有必要修改它)。
• 编程语言是关于功能的，数据库是关于数据的。您可以在数据库中具有编程功能，但我认为它应该仅限于影响数据的组件。
• 更容易实现新的需求(例如:如果客户想要API)。
• 通常，当他们在数据库中使用逻辑时，代码中实现的其余逻辑更像意大利面(例如，随机函数)。
• 通常，比数据库管理员(DBA)拥有更多的程序员更常见。哪种实现是最好的？

Answer 1

有关前面的讨论，请参见数据库应该实现多少业务逻辑？。

一般来说，每个人都希望在自己控制的层面上完成任务。因为那样他们就能控制它。

每个数据库供应商都希望人们将尽可能多的逻辑放入数据库中。因为那会把你锁在数据库里。理由是，如果多个应用程序使用相同的数据库，它们将重用代码。

然而，程序员显然不同意。数据库提供了糟糕的编程选项。将代码部署到数据库很困难。数据库缺乏用于修订控制、交互式编辑、部署和单元测试的基本工具。存储过程往往涉及可怕的远程调试操作。让多个应用程序访问同一个数据库已经变得不那么常见了。如果你要做一些事情，最难解决的瓶颈就是你的数据库。

我的偏见很明显。我是个程序员。

但是我已经编程了近20年，主要是作为一个负责数据的后端程序员。我已经多次看到将逻辑移到数据库中的论点。我见过这样做的系统和避免它的系统。我不得不迁移数据库、迁移代码库等等。

最糟糕的混乱总是发生在数据库中的业务逻辑。它们总是最难修复的。我可以说，虽然我多次遇到这样的说法：“我们将逻辑转移到数据库中以提高性能”，但是如果有一个干净的规范化数据模型、良好的索引、数据库前面的缓存层以及用现代编程语言实现的健全的算法，性能几乎总是会更好。

Answer 2

我非常坚定地认为，如果可能的话，业务逻辑应该保存在软件层，而不是数据库层。请注意，在任何可能的情况下，总是远远不够。

这两种方法都有很强的论据，而且像往常一样，在决定哪一种更合适的选择之前，要用工程上的良好判断来决定每个项目应该有多少权重。

(当其他人在评论中提出建议时，可以将它们添加到列表中)

数据库处理业务逻辑的

参数：

• 业务逻辑需要对数据进行操作。使逻辑处理尽可能接近数据可以提供更好的性能。
• 一个应用更新的地方

处理业务逻辑的软件层的

参数：

• 与SQL存储过程相比，编写良好的软件通常更容易理解、调试和维护。
• 如果internet应用程序变得流行，应用服务器既可以扩展，也可以扩展。

作为一名经验丰富的专业开发人员，需要快速修复以改善应用程序延迟，可以选择将一些缓慢运行的业务逻辑迁移到数据库上的存储过程和/或实现慢进程的缓存。

但是，基于数据库的业务逻辑有一个严重的问题。如果您的应用程序需要大规模扩展，那么总是更喜欢可以扩展的系统/进程(我的意思是，您可以在处理池中添加更多的服务器)。SQL数据库只能扩展(您需要找到更强大的服务器来替换现有的服务器)。如果您的应用程序具有大量的数据库业务逻辑，那么您将更早地遇到这个问题。

Answer 3

在支持数据库的论点中缺少两个非常重要的要点：

• 性能:通过直接访问数据来执行数据库代码，从而避免不必要的传输(无论是跨获取API和同一台计算机上的映射方案，还是跨网络进行客户机/服务器通信)
• 一致性:由于几个应用程序可以访问/更新同一个数据库，将一致性和业务规则集中封装在其中，可以确保它们得到可靠的执行。

但是，在反向数据库的论点中也遗漏了一些非常重要的要点：

• 可伸缩性:您在数据库上放置的越多，这个组件就越会成为瓶颈。当然，您可以使用更大的服务器并添加CPU，但迟早您会满足物理限制。
• 供应商锁定: SQL是非常标准化的，但是触发器和过程的语言是相当多样化的，而且常常是专有的:微软的T-SQL，甲骨文的PL/SQL，DB2的任何语言。在数据库上进行开发将您锁定为供应商，不允许您从竞争加剧中获益，也不允许您迁移到新的操作环境。
• 遗留体系结构:数据和处理过度集中在大型服务器上.难道这不让我们回到大型机时代吗？这在当今看来已经过时了，因为新的主要架构趋势出现在最大的可伸缩性上:灵活的NoSQL 不同类型数据库非常适合面向对象的开发，每个微服务都有自己的数据库的微服务，以及大数据体系结构(如lambda体系结构 )，其中所有处理管道都在数据库之外。
• 过时的论点:跨应用程序复制容易出错的冗余cobol代码的时间已经结束。昨天只能可靠地封装在RDBMS中的东西，可以很好地封装在现代软件体系结构中，使用可维护和可重用的面向对象组件、库和版本控制系统。

概括地说：

• 是的，在数据库端设置最大逻辑的参数是有效的。然而，这些论点已不再满足互联网规模、技术转移和大数据的出现的新需求和限制。
• 不，我不认为有一种普遍的最佳方法。最合适的方法应由软件架构师根据具体的要求和需要逐案选择。