为什么数据库特性被忽略,而在中间层被重新设计?

• 通常比大多数中间层语言能力差;

也就是说,这是C#的常用方法ASP.NET应用。

正如杰夫·阿特伍德所说, stored procedures are the assembly language of databases 人们不倾向于用汇编语言编写代码,除非他们需要。

我经常使用物化视图,有时在Oracle中使用connectby,我认为MySQL中不存在这两种视图。

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

另一个问题是,如果您超越了ansisql(很多),那么您只是在某种程度上将自己与某个特定的数据库供应商联系在一起,也可能与某个特定的版本联系在一起。由于这个原因,您经常会发现应用程序开发人员倾向于以最低的公分母来对待他们的数据库,这意味着将它们视为关系数据的垃圾场。

因为开发人员不了解SQL。它们依赖于Hibernate等工具生成的DDL和DML以及JPA注释等语言级构造。开发人员不在乎这些是不是非常低效,因为它们被正常的日志级别所隐藏,而且dba不是开发团队的一部分。

所以我喜欢工具 iBATIS . 它们使您能够编写和理解SQL,包括DBMS特有的特性。

这并不是经常说的,但是使用特定于供应商的特性的好处需要与成本进行权衡。主要是重写依赖于供应商特定特性的部件的成本。当供应商提供更好的方法时,如果您以通用的方式实现某些东西,也会有性能成本。

我将举一个例子:一旦意识到Analysis Services、Reporting Services等可以为您的应用程序做的所有事情,人们可能会发现sqlserver的“锁定”更容易被接受。对于主要的商业数据库系统,需要考虑的不仅仅是SQL数据库引擎。

因为很多所谓的开发人员对数据管理一无所知,更糟糕的是,他们也完全不知道自己的无知。”对他来说,这是一个警钟。

如果您的软件在客户机的硬件上运行,那么对数据库的任何更改(新存储过程、更新的视图等)都需要DB管理员权限。这几乎总是客户的问题。涉及DB组会使您需要做的任何更新复杂化。这里有很多很好的理由,但这是我唯一需要避免像瘟疫一样将代码放入数据库的理由。

我想其中一个原因是担心供应商被锁定。这些DBMS特性不是标准化的—例如,存储过程是非常特定于DB的,如果您使用存储过程(而不是通过中间层公开的web服务)实现了一些东西,那么您将永远只能使用最初选择的DBMS(也就是说,除非您愿意花费时间/金钱在另一个DBMS中重新实现它)如果您想更改DBMS)。

当web应用程序在20世纪90年代末和21世纪初爆发时,MySQL的版本是3.3或4.0,不支持任何简单的应用程序 SELECT s、 但是,它是免费的,并且安装在大多数Linux发行版中。结果,一代程序员没有学习数据库,也不知道如何使用它们。

即使现在MySQL是5.1版本,并且支持商业系统的大部分功能,当一个新的LAMP项目启动时,同样粗糙的旧博客和文章也被用作模板,MySQL被部署了MyISAM表和3.3时代的功能。

凡人即使用最简单的语言也会失败。也许十分之一的人确实有能力使用像C#这样的直截了当的语言。但在这10%中,只有十分之一或1%的人能有效地使用SQL或Haskell等语言。

现在,SQL作为一种语言是不完整的,因为只有SQL可以做的事情很少。你总是需要另一种语言。那留给SQL的角色是什么?开发人员将了解ACID相对于平面文件存储的优势,但除此之外,数据库实际上没有什么可以提供的。

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

他们只学会了最简单的SQL,并没有意识到不同rdbms提供的所有不同的扩展。

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

... 我认为这个问题就像“为什么不更多的人使用 特征x 语言y “——如果他们不是这方面的专家 他们可能不知道 特征x

(不要把这当作获得DBA认证的支持。。。我认识一些甲骨文数据库管理员,他们不能从湿麻袋中编程;我在8i天内修了所有课程,但拒绝参加考试,因为我不想和那群人混在一起)

我认为,当多个应用程序共享同一个数据时,关系数据库系统变得非常重要,这一点盖过了所有其他应用程序。Codd的著名论文名为“大型数据库的数据关系模型” 数据库”(我的重点)。

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

但在许多情况下(当然不是所有情况;每种情况都不同),这种开发模式在长期内并不能很好地发挥作用。随着应用程序生成的数据不断积累,并且对业务越来越重要,不同的人将对如何使用这些数据产生有趣的想法。当这种情况发生时,如果您没有关系数据库管理系统,您将面临一个巨大的挑战。

我遇到过太多的情况,公司政治(“我们不允许访问SQL Server,所以让我们安装一个功能较弱的DBMS,比如access,来处理数百万行并将其与另一个表中的数百万行连接起来,并让自动导入…”)甚至可能发生的技术政治(“我知道access可以处理这个问题数据量,即使没有,我们也可以将MDB拆分为多个MDB并引用它们……“)

另一个例子-我认为没有理由不在百分之百使用SQL Server的Microsoft商店中使用存储过程 数据库管理系统的选择。但是,由于最终将拥有解决方案的IT人员对SPs“不感兴趣”,我不得不采取其他措施。我的意思是,有一个完美的例子,为什么一些“功能”在他们的商店被忽略了。

我知道另一家商店仍然使用DOS Foxpro 2,因为他们唯一的IT人员就是这样编写现有系统的,所有新东西都是这样开发的。为什么?我们不能与时俱进吗?那里的许多营销人员同时打开了几个DOS提示,其中运行着Foxpro“jobs”,生成了我见过的最难看的报告。但它是有效的-我会给他们的。它是有效的——它们的主表中有1200万行,还有50多个其他表,它们与主表“连接”(显然不是一次全部连接50行),但是人。。。已经过了1991年!他们甚至不想讨论你在问题中提供的项目清单中的一项。

我想这就是为什么。

我想说最大的原因是大多数人不知道他们。一旦有人找到了一个问题的解决方案,这将成为类似问题的默认解决方案。SELECT*FROM table已经为很多人工作了很长一段时间,所以他们不必费心去寻找解决老问题的新方法。

另一个原因是,有时用代码编写要比使用数据库容易得多。这与滚动自己的组件与购买现成组件的想法相同。使用预先编写的特性可以多次解决问题,但是每隔一段时间,您就需要做一些预先编写的组件无法执行的事情。

问得好,讨论得好。

另一种说法是“为什么对象DBs还没有流行起来?”这是硬币的另一面。DBs仍然是一个恼人的抽象,仍然会泄露到每个应用程序中,但它们与现代应用程序的OO逻辑不兼容。

答案是“不会很长时间”,同时,在许多情况下,随着中间层功能的增长,希望DB被忽略,被压缩,只用于行存储,以弥补差距。

另一个问题是“如果中间层可以做,我为什么要在DB中做?”中间层很熟悉,并且一直在速度和功能上取得进展。同样,我们使用中间层来避免OO-RDMS不匹配。

前进什么 Christian 说到可扩展性。

简单地说,RDBMs更多地被用作纯数据存储,而逻辑已经迁移到应用服务器。AS的额外层比使用RDBMS作为应用服务器更为灵活。

以前,在Fat应用程序和客户端服务器的经典时代,DB和应用服务器基本上是一样的。应用程序逻辑要么嵌入到胖客户机代码中,要么将其推回到RDBMS中。但在那时,主要的通信形式是直接与数据库进行SQL通信。

如今,其他应用程序协议更为常见(CORBA、DCOM、远程EJB,以及如今越来越常见的基于HTTP的XML/JSON/HTTP-RPC样式的协议)。大多数数据库不直接响应这些协议,因此应用程序层被插入以拦截这些调用,而该层调用数据库。

当你的应用程序层是存储过程上面的一层薄薄的贴面时,质疑它为什么会存在是有道理的。

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

对我来说,原因不仅在于我的应用程序与数据库无关,而且数据库最好地执行基本的CRUD函数。是的,数据库是高度优化的,也许可以进行HTTP调用,但为什么要这样做呢?webservice/web应用程序针对HTTP调用而不是数据库进行了优化。就像应用程序不是直接连接到数据文件并检索数据一样。能做到吗?是的,但是为什么?这不是你的应用程序擅长的。

简而言之:这些特性中有很多对于OO开发是不实用的。我知道DBA不喜欢听这些,但这是事实。这些特性适用于边缘情况,大多数优秀的ORMs(如N/Hibernate)都允许您为这些边缘情况提供SQL。

长话短说:我认为RDBMS世界正在经历成长的阵痛,并且正在世界上找到自己的位置。真相:OOP比RDBMS更古老。OOP只是从成长的痛苦中走出来,逐渐成熟。我认为SQL作为一种语言已经非常成熟了,但是RDBMS应该处理什么的想法刚刚确定下来。在Java和C出现之前,RDBMS一直是大多数web应用程序的业务逻辑持有者。我想我们现在才刚刚开始感觉到这种修正。

也就是说,我不认为任何ORM设计者会告诉你,提供给RDBMS的sql语句的质量无关紧要。

说到非积垢

当涉及到将相同的逻辑实现到DB或中间层时,没有足够的开发人员在一个级别上了解所有这些特性,而这些特性对于一个普通的“中间层”程序员来说确实是有区别的。也许真正深入了解这些特性的人是dba。而这些关注的是发展以外的其他问题。比dba有更多的“普通”开发人员。因此,为您的团队找到合适的人将是非常困难和昂贵的。

一

我认为原因是供应商锁定和大多数RDBM用户缺乏知识。SQL是一种编程语言,掌握调用SQL的源语言和SQL都比掌握其中一种要困难得多,特别是因为SQL是一种特别独特的语言。

我认为,解决方案是将您的数据库功能抽象为一个实用程序类,并将该类的所有权交给一些知道如何使用SQL的用户。这将供应商锁定的风险降到了最低(如果您切换供应商,唯一被重写的就是类)。这也为不擅长SQL的开发人员提供了一个抽象的接口,这样他们就不必直接处理数据库。

我所看到的利用增加的数据库功能的一个问题是可伸缩性。与web/应用服务器负载相比,扩展数据库负载似乎要困难得多。

您的选择是有限的,可以使用更大更快的硬件进行扩展(有时许可成本要高得多),也可以使用只读拷贝进行复杂的扩展,等等。

如果存在性能问题,我希望它们处于web服务器应用程序级别。至少我的一个选择是添加另一个web服务器并分配负载。

我并不反对使用数据库级代码来最小化web服务器和数据库服务器之间发送的网络通信量(记录)。我反对其他特性,例如在数据库级别进行广泛的业务逻辑处理。

一些帖子指出,在应用层进行扩展比在db层进行扩展更便宜。

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

因为用宿主语言编写面向对象的软件,使用本地宿主语言对象,胜过编写过程软件。

• 由于许可证费用或IT政策的原因,客户可能不愿意在您希望时更新数据库软件。
• 即使像物化视图这样的基本特性也只存在于数据库软件的某些版本中,较小的客户通常不愿意为数据库的高端版本付费。
• 在中间层编写一次逻辑,或者至少在数据库中编写PL-SQL和TSQL是一个简单的选择!
• 对数据库的任何更改(新的存储过程、更新的视图等)都需要DB管理员权限;在某些客户站点上,这比只更新软件要困难得多。
• 编写脚本来更新数据库总是比安装新版本的应用程序DLL更困难。(现在大多数构建系统都将MSI文件作为每个构建的一部分输出)
• 调试存储过程比调试C#更困难。
• 仅仅因为它在您的数据库上工作并不意味着它将在客户数据库上工作,RDBMS有太多的开关,这些开关会改变它们的工作方式客户总是倾向于以不同的方式设置它们。

考虑到以上所有因素,使用数据库特性的好处 一定很棒 才值得长期的痛苦。