为什么数据库功能被忽略，而在中间层被重新发明？

除了“数据库独立性”之外，当今的大多数IT项目似乎都忽略了Oracle 11g和SQL Server 2008等现代数据库引擎中存在的众多功能的主要原因（除“数据库独立性”之外）？

或者，从赫尔辛基宣言博客中借用这样的内容：

在过去的二十年中，我们发现DBMS内部可用的功能（功能）呈指数增长。这些功能使我们能够构建数据库应用程序。这就是我们在蓬勃发展的90年代开始做的事情。

但是在新千年来临之际，发生了一些事情。而且这种神秘地使DBMS在数据库应用程序项目中的角色逐渐减少到微不足道。（...）从新千年开始，我们正在将所有应用程序逻辑从DBMS推出到中间层服务器。在DBMS外部实现的东西的功能已经爆炸式增长，并且功能丰富的DBMS几乎没有用于行存储。

我们正在谈论诸如

• 用作数据API的存储过程（出于安全性和避免过多的网络流量）
• 物化视图
• 代替触发器
• 分层查询（连接方式）
• 地理（空间数据类型）
• 分析（超前，滞后，汇总，多维数据集等）
• 虚拟专用数据库（VPD）
• 数据库级审核
• 闪回查询
• 数据库中的XML生成和XSL转换
• 来自数据库的HTTP标注
• 后台作业计划程序

为什么不使用这些功能？为什么大多数Java，.NET和PHP开发人员都坚持使用“ SELECT * FROM mytable”方法？

因为存储过程：

• 添加另一种开发语言，增加复杂性和潜在的冗余代码（用两种语言编写的逻辑）；
• 通常，其工具，监视和调试功能比PHP，C＃，Java，Python等差；
• 通常不如大多数中间层语言那么强大；
• 高容量数据转换（避免服务器往返）仅具有一个优势，而这往往只是实际使用的最低限度。

话虽这么说，它是C＃ASP.NET应用程序上的一种通用方法。

就像Je​​ff Atwood所说的那样，存储过程是数据库的汇编语言，人们只有在需要时才倾向于使用汇编语言进行编码。

我在Oracle中经常使用物化视图，有时在CONNECT BY中使用，我相信在MySQL中都不存在。

我不倾向于在数据库中使用XML / XSLT，因为那意味着我正在使用XML和XSLT。

对于地理或空间数据结构，可能是很难“拾取”它们的原因。这是一个相当专业的领域。我已经阅读了关于空间数据结构的MySQL手册，并且我相信这对具有丰富GIS经验的人来说是有意义的，但对我和我的有限需求（往往围绕标记点的纬度/经度）来说，它确实没有似乎不值得花时间进行弄清楚。

另一个问题是，如果您超出了ANSI SQL的范围，那么您将自己与特定的数据库供应商以及特定的版本绑定在一起。因此，您经常会发现应用程序开发人员将倾向于以最低的公分母来对待他们的数据库，这意味着将它们视为关系数据的垃圾场。

因为开发人员不了解SQL。它们依赖于由Hibernate之类的工具生成的DDL和DML，以及诸如JPA注释之类的语言级别构造。开发人员不在乎这些效率是否非常低，因为它们被正常的日志级别很好地隐藏了，并且因为DBA不在开发团队中。

这就是为什么我喜欢iBATIS工具。它们使您能够编写和理解SQL，包括DBMS特定的功能。

我想原因之一是担心供应商锁定。

这并不是经常说出来的，但是需要权衡使用供应商特定功能的好处和成本。主要是为每个要支持的数据库重写依赖于特定于供应商的功能的部件的成本。如果您在供应商提供更好的方法时以通用方式实现某些目标，则还会降低性能。

我将举一个例子：一旦意识到Analysis Services，Reporting Services等可以为您的应用程序完成的所有工作，人们可能会发现SQL Server的“锁定”更容易被接受。对于主要的商业数据库系统而言，并非仅是需要考虑的SQL数据库引擎。

“为什么数据库功能被忽略”。

由于许多所谓的开发人员完全不了解数据管理，更糟糕的是，他们也完全不了解自己的无知。“不熟练且不了解它的人”，这为他敲响了警钟。

如果您的软件在客户端的硬件上运行，则对数据库的任何更改（新的存储过程，更新的视图等）都将需要数据库管理员权限。对于客户来说，这几乎总是一个问题。涉及数据库组会使所需的任何更新复杂化。这里有很多很好的理由，但这是我唯一需要避免将代码像瘟疫一样放入数据库的理由。

我想原因之一是担心供应商锁定。这些DBMS功能不是标准化的-例如，存储过程是非常特定于DB的，并且如果您使用存储过程（而不是通过中间层公开的Web服务）来实现内容，那么您将永远被最初选择的DBMS所束缚，（也就是说，如果您想更改DBMS，除非您愿意花费时间/金钱在另一个DBMS中重新实现它）。

MySQL的。

当Web应用程序在1990年代末和2000年代初爆发时，MySQL的版本为3.3或4.0，并且不支持simple以外SELECT的任何版本。但是，它是免费的，并且已随大多数Linux发行版一起安装。结果，一代程序员都不了解数据库，也不知道如何使用它们。

即使现在MySQL已达到5.1并支持商业系统的大多数功能，当启动新的LAMP项目时，相同的原始博客和文章仍被用作模板，并且MySQL部署了MyISAM表和3.3时代功能。

SQL失败的原因与例如Haskell相同。决定语言成功与否的标准不是纯度，不是计算机易于解释，而是维护用其编写的程序有多困难。

凡人即使使用最简单的语言也会失败。也许十分之一的人确实具有使用像C＃这样的简单语言的技能。但是在这10％的人中，只有十分之一或1％的人可以有效地使用SQL或Haskell这样的语言。

现在，从某种意义上说，仅使用SQL几乎无能为力，因此SQL作为一种语言是不完整的。您将永远需要另一种语言。这对SQL有什么作用？开发人员将了解ACID相对于平面文件存储的优势，但除此之外，数据库确实没有提供这些优势。

第二个问题是SQL实际上与源版本控制不是很兼容。SQL似乎真的是建立在您第一次正确的想法上的。因此，它不仅不适合开发人员，而且与开发过程也不匹配。

修复/重新部署中间层比使用DBMS更容易。

这可能取决于您的体系结构，但这是我们的原因。再加上我们只有一名DBA，他的工作更忙，而且薪水可能比我们的开发人员还高。所有开发人员都知道SQL，其中一些人精通程序语言。如果出现了一个非常棘手的生产问题，那么开发人员在中间层上比在数据库上工作更容易和更快，而不管体系结构是一种还是另一种更好。

我遇到了很多人，他们只是不知道存在这样的功能-他们在mySQL的早期就咬牙切齿，他们从未真正使用过其他任何东西，而且还没有跟上mySQL中新存储表的改进，甚至。或者他们在学校学习数据库，他们再也没有回过头来查看他们错过的所有内容。

他们学习了最少的SQL知识，却没有意识到不同的RDBMS提供的所有不同扩展。

在一个项目中，我很想拥有物化视图...但是我正在使用Postgres。我很想在另一个项目中使用空间数据类型，但是我将不得不进行修改或更改数据库以应对mySQL坚持认为它们不为null的要求。我什至不得不弄清楚如何禁用Oracle的事务一致性来处理OLTP上长时间运行的查询，而这在mySQL中是没有问题的。

对于给定的问题，我通常可以绕数据库的缺点进行编码，但是问题的一部分在于为工作选择合适的工具-在当前项目中，我们浪费了数月的数据复制时间，因为使用Postgres，他们在真正知道我们将要复制的所有内容之前决定使用Slony-1。

......我认为这个问题作为像“为什么没有更多的人使用功能X在语言Y ” -如果他们不以专家语言Y，他们可能不知道的功能X的存在。

（并且不要以此作为获得DBA认证的支持……我知道一些Oracle DBA不能通过湿袋编程，我已经参加了8i天的所有课程，但是拒绝参加考试，因为我不想和那个人混在一起）

我认为使所有其他信息黯然失色的最大原因是，当多个应用程序共享同一数据时，关系数据库系统变得更加重要。Codd的著名论文标题为“大型共享数据库的数据关系模型”（重点是我的）。

人们倾向于认为他们现在正在编写的应用程序将始终由其团队控制。并且它将始终满足对应用程序生成的数据感兴趣的人们的所有需求。如果出现新需求，可以通过向现有应用程序添加新功能而不创建新应用程序来满足。

但是在很多情况下（当然，不是全部；每种情况都不尽相同），该开发模型从长远来看并不是很好。随着应用程序生成的数据的积累和对业务的重要性，不同的人将对如何使用数据有有趣的想法。发生这种情况时，如果您没有关系数据库管理系统，那么您将面临巨大挑战。

可扩展性。您对数据库服务器所做的工作越多，瓶颈就越大。具有整个负载平衡的应用程序服务器场来处理数据，并且仅将数据库用作持久性存储，这具有更大的可伸缩性。

在很多情况下，公司政治（“我们不允许访问SQL Server，因此让我们安装功能更弱的DBMS（如Access）来处理数百万行并将其与另一个表中的数百万行联接，并使导入自动进行） ..”）甚至是可能发生的技术政策（“我知道Access可以处理那么多数据，即使不这样做，我们也可以将MDB拆分为多个MDB并引用它们....”）

啊。公司政治和技术政治甚至是无知使我无法使用许多功能。

另一个例子-我看不出有什么理由不使用100％的微软商店，SQL Server是存储过程中选择的DBMS。但是，由于最终将拥有该解决方案的IT人员对SP十分了解，因此我不得不采取其他措施。我的意思是，有一个很好的例子说明为什么有些“功能”在他们的商店中被他们忽略了。

我知道另一家仍在使用DOS Foxpro 2的商店，因为他们唯一的IT专家以这种方式编写了现有系统，而这就是所有新内容的开发方式。为什么？不能与时俱进吗？那里的许多市场营销人员会同时打开多个DOS提示符，其中运行Foxpro的“作业”以生成我见过的最丑陋的报告。但这有效-我会给他们的。它行得通-他们在主表中有1200万行，并且与该主表“联接”了50多个其他表（显然不是一次全部50个），但是……直到1991年！他们甚至不想讨论您在问题中提供的项目符号列表中的一项。

我猜是这样的东西。

我要说的最大原因是，大多数人对此一无所知。一旦有人找到了问题的解决方案，它将成为类似问题的默认解决方案。SELECT * FROM table在很多人身上已经使用了很长时间，因此他们不必费心寻找解决旧问题的新方法。

另一个原因是，有时用代码编写它比使用数据库要容易得多。这与自己动手购买现成组件的想法相同。使用预写功能可以多次解决您的问题，但有时，您需要做的事超出了预写组件可以执行的功能。

好问题，好讨论。

另一种表达方式是“为什么没有对象DB流行起来？” 这是硬币的另一面。数据库仍然是一个令人讨厌的抽象，它仍然泄漏到那里的每个应用程序中，但是它们与现代应用程序的OO逻辑不兼容。

我们隐藏并复制ActiveRecord，Hibernate和其他中间件中DB的功能确实是一种奇怪的状况。但这就是范例在断裂点发生的情况（“对象关系阻抗不匹配”）。我们是否会过渡到与我们的OO应用程序相似的数据库技术（例如，对象DB）？

答案是“不会很长时间”，与此同时，随着中间层功能性的弥合，DB会在许多情况下被忽略并压缩并仅用于行存储。

另一个问题是“如果中间层可以做到，为什么我要在数据库中做到这一点？” 中层很熟悉，并且一直在速度和功能方面不断发展。同样，我们使用中间层来避免OO-RDMS不匹配。

继续讲克里斯蒂安所说的关于可伸缩性。

简而言之，RDBM被更多地用作纯数据存储，而逻辑已迁移到应用服务器中。与将RDBMS用作应用程序服务器相比，AS的附加层为开发人员提供了更大的灵活性。

以前，在Fat Apps和Client Server的经典时期，DB和Application Server基本上是同一件事。您已经将应用程序逻辑嵌入到胖客户端代码中，或者将其推回到RDBMS中。但是在那时，通信的主要形式是直接与数据库进行SQL通讯。

如今，其他应用程序协议更为常见（CORBA，DCOM，远程EJB，以及如今越来越常见的基于HTTP的XML / JSON / HTTP-RPC样式协议）。大多数数据库不会直接响应那些协议，因此插入了Application层以拦截这些调用，然后该层调用数据库。

但是，正如我们所了解的那样，我们现在在将逻辑放入这一层时有了更大的灵活性。工具的选择范围更大，在缓存，故障转移甚至数据库技术（RDMBS，OODBMS，CouchDB之类的文档存储）方面更具灵活性。尽管增加了复杂性，但该“第三层”比其引入的复杂性增加了更多的灵活性和功能。

如果您的应用程序层是存储过程中非常薄的单板，那么质疑为什么它甚至还存在就很有效。

利用数据库及其所有功能，即使在今天，也是一种有效的应用程序策略。SQL Server，Oracle等是功能非常强大的软件。

即使这样，第三层对于增加现代系统的灵活性也有很大帮助。

对我来说，原因不仅是我的应用程序与数据库无关，而且数据库最好地执行了基本的CRUD功能。是的，数据库经过高度优化，也许可以进行HTTP调用，但是为什么要这么做呢？Web服务/ Web应用程序针对HTTP调用（而非数据库）进行了优化。就像应用程序并非旨在直接连接到数据文件并检索数据一样。能做到吗 是的，但是为什么？那不是您的应用程序擅长的。

我个人认为，存储过程之外您提到的所有内容都属于该应用程序。如果您知道您的体系结构是X，则可以利用X的功能，在适当的时候将负载转移到数据库服务器，等等。。。如果它是X或Y（或Z），那么您的应用程序应该是不可知的，除非您通过确保您可能必须重构应用程序来尝试创建作业安全性：）。我认为有点懒惰，再加上舒适性，可能与它有关。我知道，如果可以的话，我宁愿使用C＃而不是SQL。。。我的C＃技能更好。

首先，首先，如果他/她认为使用ORM否定了必须具备SQL技能，那么任何使用ORM的开发人员都会天真。大多数生成SQL的ORM会根据对象查询的构造方式来改变发出的SQL。开发人员将需要分析SQL，以查看他们是否应该更改任何对象查询。

简短的答案：这些功能中的很多对于OO开发都不实用。我知道DBA不想听到这个消息，但这是事实。这些功能非常适合极端情况，而大多数好的ORM（例如N / Hibernate）都可以为这些极端情况提供SQL。

当主要是委托给CRUD时：

长答案：我认为RDBMS世界正经历着日趋成熟的痛苦，并且正在世界中找到自己的位置。真相：OOP早于RDBMS。OOP只是摆脱了不断增长的痛苦和日趋成熟。我认为SQL作为一种语言已经非常成熟，但是RDBMS应该处理什么的想法才刚刚确定。在Java和C＃出现之前，RDBMS一直是大多数Web应用程序的业务逻辑持有人。我认为我们现在才开始感受到这种纠正。

话虽这么说，我认为没有任何ORM设计人员会告诉您提供给RDBMS的sql语句的质量无关紧要。

对于非CRUD，我这里没有答案。我所知道的大多数商店仍然将DB用于ETL / etc ...

当要在数据库或中间层中实现相同的逻辑时，没有足够的开发人员知道所有这些功能，这些水平对真正的“中间层”程序员而言确实会有所不同。也许真正了解这些功能的人是DBA。这些关注的焦点是发展以外的其他问题。那里的“普通”开发人员比DBA多。因此，很难为您的团队找到合适的人。

另一点是，您通常只会收集有关一个数据库系统的深入知识，而不是全部。因此，您可以拥有SQL Server专家或Oracle专家，但不能同时拥有。这在一定程度上导致了狭窄的应用领域，在这些领域中，专业化非常重要。这样，即使存在，此类应用程序的市场也不大。

我认为原因是供应商锁定和大多数RDBM用户缺乏知识的结合。SQL是一种编程语言，要掌握您从中调用SQL的语言和掌握SQL的语言比掌握一种或另一种语言要困难得多，尤其是因为SQL是一种特别的语言。

我认为，解决方案是将数据库功能抽象为实用程序类，并将该类的所有权提供给一些知道他们使用SQL做什么的用户。这样可以最大程度地减少供应商锁定的风险（如果切换供应商，则唯一需要重写的是类）。这也为不是SQL专家的开发人员提供了抽象的接口，因此他们不必直接处理数据库。

我所见到的利用增加的数据库功能的一个关注是扩展。相对于Web /应用程序服务器负载而言，要扩展数据库负载似乎要困难得多。

您的选择是有限的，使用更大的更快的硬件（有时会增加更高的许可成本）进行扩展，或者使用只读副本进行扩展等。

如果存在性能问题，我希望它们出现在Web服务器应用程序级别。至少我的选择之一是添加另一台Web服务器并分配负载。

我并不反对使用数据库级代码来最大程度地减少Web服务器和数据库服务器之间发送的网络流量（记录）。我在反对其他功能，例如。在数据库级别进行广泛的业务逻辑处理。

一些帖子指出，在应用程序层进行扩展比在数据库层进行扩展便宜。

另一个考虑因素是访问多个数据存储的复合应用程序。与在db层中单独使用特定于平台的查询相比，在应用程序层中编写和维护与平台无关的查询语言要容易得多。

因为用宿主语言编写带有本地宿主语言对象的面向对象软件优于编写程序软件。

我一直在销售给许多客户端并在客户端硬件上运行的系统上工作。这将导致：

• 您不知道客户端将运行哪个版本的数据库软件。
• 由于许可成本或IT策略的影响，客户可能不愿意在需要时更新数据库软件。
• 即使诸如物化视图之类的基本功能也仅存在于数据库软件的某些“版本”中，较小的客户通常也不愿意为数据库的高端版本付费。
• 您的销售人员迟早会同意您的软件与其他供应商的RDBMS一起使用。
• 选择在中间层编写一次逻辑，还是至少在数据库中编写PL-SQL和TSQL，这是一个容易的选择！
• 对数据库的任何更改（新的存储过程，更新的视图等）都将需要数据库管理员权限；在某些客户站点上，这可能要困难得多，然后仅更新软件即可。
• 编写脚本来更新数据库总是比安装新版本的应用程序dll困难。（如今，大多数构建系统都会将MSI文件作为每个构建的一部分输出）
• 与中间层相比，很难在数据库中对代码进行单元测试。
• 与C＃相比，调试存储的proc更加困难。
• 仅仅因为它可以在您的数据库上运行并不意味着它将在客户的数据库上运行，RDBMS拥有太多改变其工作方式的开关-客户总是倾向于以不同的方式设置它们。

因此，鉴于上述所有情况，使用数据库功能所带来的收益必须是巨大的，才值得长期痛苦。