将应用程序逻辑放入数据库层的论据是什么？[关闭]

大多数软件开发人员都希望将应用程序逻辑保留在应用程序层中，对于我们而言，将其保留在此处可能很自然。数据库开发人员似乎希望将应用程序逻辑作为触发器和存储过程放在数据库层中。

就个人而言，我希望在应用程序层中保留尽可能多的内容，以使其更易于调试，并使各层的职责分开。

您对此有何想法，应该或不应该在数据库层中实现什么？

编辑从DBA角度来看，此问题也包含在dba.se上。由于programmers.se和dba.se的受众和偏见不同，因此未来的读者可能希望先对这两套答案进行审查，然后再确定最适合他们的答案。

在我的头上，是将逻辑放在应用程序层中的优势。

1. 可测性。实际上，这应该是一个足够好的理由。
2. 更好的代码结构。使用SQL遵循正确的OO架构非常困难。这通常也使代码更易于维护。
3. 易于编码。由于您使用的任何一种语言都具有所有不同的语言功能，因此通常更容易在应用程序层中进行编码。
4. 代码重用。与库共享代码比在数据库中共享代码要容易得多。

虽然可以将版本控制与存储过程一起使用（例如，与TFS集成的Redgate数据库工具），但它并不总是像应用程序代码那样简单。

我的默认立场是逻辑应保留在数据库层之外，但是，有时候在数据库中实现逻辑会更有效。如果是这种情况，则必须确保可以跟踪对此代码的更改。

在我工作的一家公司中，有很多繁文tape节涉及将代码发布到生产中，而涉及DBA进行代码发布始终是一场噩梦。我们始终将逻辑放在应用程序层中，以消除必须处理难以使用的DBA的麻烦。这是完全la脚的原因，但出于必要而衍生。

对我来说，将应用程序逻辑放入数据库听起来是个坏主意。OTOH在数据库中放置逻辑（这是维护数据库状态的一部分）（例如，用于更新非规范化表的触发器/过程）是非常不同的主张。

或者，可以这样表述：有很多很好的论据可以用来将逻辑从数据库看待数据库的方式中抽象出来。

阅读了两个问题，我认为我们可能都错过了一个关键点。正确答案可能取决于您所开发的软件类型。DBA小组倾向于在关键业务企业软件系统上工作，而他们的答案往往反映出该世界所需要的东西。这些类型的应用程序所需要的与下一个“ Facebook”应用程序所需要的有很大的不同。如果您丢失了几个贴子，这没什么大不了的，如果您丢失了几个订单或其他金融交易，也没关系。

出于销售原因，在COTS（商用现货）领域工作的人们往往需要与数据库无关，并且他们希望使用标准代码编写的所有内容都使反向工程和用自产产品替换其产品变得更加困难。内部开发和维护的企业应用程序几乎不需要更改数据库后端即可进行升级。

企业应用程序也往往是来自许多地方的输入，而数据库是唯一的通用性。我使用的系统有数百个不同的应用程序对其进行访问，以及数百种客户端数据的导入，向客户端和数据仓库的数据导出以及使用多种报告系统。当我必须导入20,000,000时，添加一条记录时运行良好的代码将失败。我们不得不使用应用程序层一次，因为那是逻辑所在，并且不得不在18小时后结束该过程，但未完成。当您无法拥有每个人都可以使用的一个数据层时，应该将应用于表中所有数据记录的逻辑放在数据库中。

相反，当仅一个应用程序将使用数据并且数据不是公司的命脉或临时性数据时，规则会有所不同，并且将所有逻辑放入应用程序中就更有意义了。

长。请参阅底部的摘要。

关系数据库管理系统

RDBMS代表关系数据库管理系统。这是一个管理关系数据库的系统。数据存储在那里。数据。它没有说业务逻辑。

业务流程

业务逻辑真的意味着什么？对我来说，这是用逻辑术语描述业务流程的。

流程是指那些定期发生的业务活动，足以使它们不再是临时的。这些对于每个企业都是不同的。

让我戴上商务帽，并在此说明业务的含义。对于某些人来说，这可能令人惊讶。

商业

商业是为实现价值创造而开展的活动的总和，更具体地说是可以交易的价值。这可能意味着制作联合收割机，金枪鱼三明治或提供银行服务。在世界上大多数国家，即使是非资本主义国家，人们也希望物有所值，因此，这些有价值的商品和服务的提供者之间存在竞争。竞争通常取决于价格，质量和可用性。

快速绕道：您需要在两天内获得4000万个铆钉，无论您的价格比正常供应商的价格便宜多少，您都不会通过互联网上的某个人使用Paypal帐户订购。

工艺知识

可以想象，实现“价值”的过程大部分存在于行政首长中。其中一些已写在纸上，用作公司的政策和程序。其中一些生活在公司法律顾问的头上。其中很多生活在负责部门，部门，团队以及负责机器，收银机，烤箱，卡车的人员的头脑中。其中的一小部分使它无法满足软件的业务需求，而到计算机系统中实现时，其中的一小部分就可以实现精确化。

最后，您在代码中看到的业务逻辑不是运行业务的逻辑，而是运行业务应用程序的逻辑。实际人员内部的实际大脑拥有实际的业务流程，他们毫无疑问地了解到他们大脑中的流程比计算机中的流程更准确。顺便说一句，如果您拥有的只是大多数公司的政策和程序，那么您可能无法经营公司。尽管付出了艰辛的努力，但通常情况下，这些都是非常不准确的。

因此，最后，是将应用程序逻辑编码到软件中。人们希望将其放入数据库中，因为数据库管理系统供应商提出了宏伟的主张。

应用逻辑

我拒绝。我说应用程序逻辑留在应用程序内部。数据以非常规范的方式进入数据库，然后将ETL发送到数据仓库，以进行报告，钻取，汇总，数据透视和计算。

数据

我还说数据比应用程序寿命长，因此数据规范化工作不应针对特定应用程序，甚至不针对特定业务，而应针对一般业务。您是否存储州代码？您应该使用INCITS 38：2009（http://www.census.gov/geo/www/ansi/statetables.html），因为它可以跨企业移植。这也使多个应用程序更容易操作数据。

NoSQL？

如果您将数据库视为应用程序代码的一部分，从表布局到触发器，存储过程和数据格式，则实际上是在将企业数据库用作美化的BerkleyDB，这是美化的平面文件结构，这实际上只是持久列表。从本质上讲，这就是NoSQL所做的：回到根源，但以多进程，持久，容错的方式进行。

实际代码

不，您需要将数据库视为当前和将来多个应用程序的通用数据存储库。现在我们来论证我的症结所在。业务流程随市场，政治和时尚的变化而变化。通常，它们的更改速度超出了编码人员可以使用计算机科学级语言（Java，C＃，C ++等）管理的范围，并且最终以VBA在会计或营销部门的excel电子表格中编写。（并且仅当它无法在精美的vlookups中表达时...）

数据库降级

如果组织得当，数据不会有太大变化。业务逻辑变化非常快。通过将业务逻辑放入数据库中，可以降低数据库的价值，因为它将很快变得过时且不准确。

摘要

数据必须比应用程序寿命更长，因为业务流程存在于应用程序中，并且业务流程的更改频率更高。在数据库中包含业务逻辑不利于其持久性和整体价值。

警告

我已经完成了dba-ing的工作，并且已经在dba.se上阅读了答案，但老实说，他们所说的是数据完整性问题和性能问题。我完全同意，接触公司数据的人应该知道他们在做什么，无论是dba还是程序员或具有读/写访问权限的SAS高级分析师。

我还指出，他们建议编码人员知道SQL。我同意。它是一种计算机编程语言，所以我不明白为什么计算机程序员不想知道它。

后来考虑了一下

我认为中间的目的是制作一个API，并让该API管理来回的数据流。如果您不允许应用直接连接到表格，则至少可以使访问机制采用现代语言。

冒着听起来惊人的风险，我对数据库中的应用程序逻辑的想法真的感到震惊。这里有很多答案都集中在软件开发优势上，因此，为了简洁起见，我将着重于责任分工所带来的优势。

数据库提供了一种有效的方式来存储和访问信息，同时将冗余数据最小化并在数据中产生逻辑关系。尽管数据库逻辑可能能够实现生产级业务逻辑，但我个人认为数据库应尽可能与应用程序无关，以确保多个应用程序可以有效利用数据，同时发挥数据库的各自优势引擎与应用程序实现语言的优势。

DBA堆栈交换上的一位用户说过这一点...

我希望所有逻辑都适用于数据库中的所有用户和所有应用程序。那是唯一可放的地方。

我工作的最后一个《财富》 500强公司的应用程序至少以25种语言编写，并使用了OLTP数据库。其中一些程序在1970年代投入生产。

...随后他相信这表明违反了DRY原则。

我认为这不是重复业务逻辑，而是更可能是业务层和数据层之间职责分工所提供的灵活性的完美示例。

数十年来，他们的OLTB数据库一直为25多个应用程序可靠而有效地提供数据！太棒了！（要走！）

我只能假设数据是不可知的，足以为许多不同的应用程序提供内容。如果那些开发人员试图使用数据库逻辑将某些东西一起黑客入侵，那将几乎是不可能的。

正如其他答案所表明的，还有许多其他原因无法在数据库中实现程序。我敢肯定它会起作用，但是最可能的结果是数十年的遗憾，而不是数十年的稳定。

与数据库无关的应用程序需要数据库中的所有逻辑。为许多不同的数据库提供程序构建和维护代码非常困难。

通过将一些逻辑放入数据库中以及将大多数逻辑放入应用程序中，良好的开发将在数据库完整性和速度需求之间取得良好的平衡。

将在许多应用程序中重复使用相同的查询，那么它可能属于存储过程。

DBA的职责是确保在插入和更新行时设置看家字段。将使用触发器。

另一方面，如果我具有业务逻辑，则它必须存在于应用程序中。它应尽可能调用存储过程，该存储过程将返回所需的，经过过滤的记录集以及所需的确切字段数。不多不少。

这是团队之间沟通的问题，也是认识每种可能性的利弊的问题。

我的观点是：不要使应用程序逻辑在DB中太深。

一些交易系统提供了一种使用脚本扩展现有功能的方法，这些脚本基本上放在数据库中。我的经验是负面的，至少在多用户环境中是如此。

您将逻辑放入数据库中，因为您希望能够轻松修改该逻辑。

• 您将如何进行版本控制？
  • 什么是代码历史记录？有哪些变化？通过谁？
  • 您如何处理相同代码段上的更改？
• 您将如何识别和保证一致的代码状态？

您可以在其他基于文件的VCS中进行跟踪，但是数据库的好处是什么？

大多数应用程序需要某种方式来提供集成。理想情况下，您将拥有完整的API，Web服务或至少使一些包含业务逻辑的数据库对象可用。每个人都没有时间/资源来构建API，因此您必须妥协。