今天大多数IT项目似乎忽略了现有数据库引擎(如Oracle 11g和SQL Server 2008)中存在的大量功能的主要原因(除了"数据库独立性")有哪些？
或者,从赫尔辛基宣言博客借用这样的方式:
在过去的二十年中,我们发现DBMS内部可用的功能(特性)呈指数级增长.这些功能使我们能够构建数据库应用程序 这就是我们在九十年代蓬勃发展时所做的一切.
但是在新千年开始之际,发生了一些事情.而神秘地使DBMS在数据库应用程序项目中的作用减少到微不足道.(...)从新千年开始,我们将所有应用程序逻辑从DBMS推送到中间层服务器.在DBMS之外实现的东西的功能已经爆炸,并且功能丰富的DBMS几乎不用于除行存储之外的任何东西.
我们正在谈论类似的东西
为什么没有使用这些功能？为什么大多数Java,.NET和PHP开发人员都坚持使用"SELECT*FROM mytable"方法？
cle*_*tus 55
因为存储过程:
话虽如此,它是C#ASP.NET应用程序的常用方法.
正如Jeff Atwood所说,存储过程是数据库的汇编语言,除非他们需要,否则人们不会使用汇编语言编写代码.
我经常使用物化视图,有时在Oracle中使用CONNECT BY,我认为这两者都不存在于MySQL中.
我不倾向于在数据库中使用XML/XSLT,因为,这意味着我正在使用XML和XSLT.
至于地理或空间数据结构,原因可能是他们很难"捡起".这是一个相当专业的领域.我已经阅读了关于空间数据结构的MySQL手册,我确信对于那些拥有丰富GIS经验但对我和我有限的需求(通常围绕标记点的纬度/经度)的人来说它是有意义的.似乎值得花时间投资来搞清楚.
另一个问题是,如果你超越ANSI SQL(那么多),那么你只是将自己与某个特定的数据库供应商绑在一起,可能与某个特定的版本绑在一起.出于这个原因,您经常会发现应用程序开发人员倾向于以最低的公分母对待他们的数据库,这意味着将它们视为关系数据的倾销场.
小智 36
因为开发人员不了解SQL.它们依赖于Hibernate等工具生成的DDL和DML以及JPA注释等语言级构造.开发人员并不关心这些是否非常低效,因为它们被正常的日志级别隐藏,并且因为DBA不是开发团队的一部分.
这就是我喜欢工具iBATIS的原因.它们使您可以编写和理解SQL,包括DBMS特定的功能.
Jas*_*aty 21
我猜一个原因是担心供应商锁定.
这并不是经常说的,但是使用特定于供应商的功能的好处需要与成本进行权衡.主要是必须为每个要支持的数据库重写依赖于特定于供应商的功能的部件的成本.如果您在供应商提供更好的方式时以通用方式实施某些内容,则还会产生性能成本.
我将提出这个例子:一旦实现了Analysis Services,Reporting Services等可以为您的应用程序做的所有事情,人们可能会发现SQL Server的"锁定"更容易被接受.对于主要的商业数据库系统,它不仅仅是需要考虑的SQL数据库引擎.
Jim*_*ard 12
如果您的软件在客户端的硬件上运行,则对数据库的任何更改(新的存储过程,更新的视图等)都需要DB管理员权限.对于客户来说,这几乎总是一个问题.涉及数据库组会使您需要执行的任何更新变得复杂.这里提出了很多很好的理由,但这是我唯一需要避免将代码放入数据库中的问题,如瘟疫.
Chi*_*hii 10
我猜一个原因是担心供应商锁定.这些DBMS功能不是标准化的 - 例如,存储过程是特定于数据库的,如果您使用存储过程(而不是通过中间层公开的Web服务)实现了东西,那么您将永远坚持首先选择的DBMS ,(除非你愿意花时间/金钱在另一个DBMS中重新实现它,如果你想改变DBMS).
MySQL的.
当Web应用程序在20世纪90年代末和21世纪初发生爆炸时,MySQL版本为3.3或4.0,并且不支持任何高于简单版本SELECT的内容.然而,它是免费的,并与大多数Linux发行版一起安装.结果,一代程序员没有学习数据库,也不知道如何使用它们.
即使现在MySQL处于5.1并支持商业系统的大多数功能,当新的LAMP项目启动时,同样使用粗糙的旧博客和文章作为模板,并使用MyISAM表和3.3时代的功能部署MySQL .
SQL失败的原因与Haskell相同.决定语言成功的指标不是纯粹,不是计算机解释的容易程度,而是维护程序编写的程序有多难.
即使是最简单的语言,凡人也会失败.也许十分之一的人都有使用像C#这样简单语言的技能.但在这10%的人中,只有十分之一或百分之一的人可以有效地使用SQL或Haskell等语言.
现在,SQL作为一种语言是不完整的,因为只有SQL才能做很少的事情.你总是需要另一种语言.这对SQL有什么作用？开发人员将了解ACID优于平面文件存储的优势,但除此之外,数据库确实无法提供它们.
第二个问题是SQL有效地与源版本控制不兼容.SQL似乎真的是建立在你第一次就做对的概念之上.因此,它不仅不适合开发人员,也不适合开发过程.
修复/重新部署中间层比DBMS更容易.
这可能取决于您的架构,但这是我们的理由.再加上我们有一个比较繁忙的DBA(可能)的事实比我们的开发人员付出的更多.所有的开发人员都知道SQL,其中一些人对程序语言非常熟悉.如果出现了一个非常毛茸茸的生产问题,那么开发人员在中间层上工作比数据库更容易,更快,无论架构是以哪种方式更好.
我遇到了很多人,他们只是不知道存在这样的功能 - 他们在mySQL的早期就切断了牙齿,他们从来没有真正使用过任何其他东西,他们没有跟上甚至,在mySQL中新存储表的进步.或者他们在学校学习数据库,他们从来没有回去看他们错过的所有东西.
他们学习了最基本的SQL,并没有意识到不同RDBMS提供的所有不同扩展.
在一个项目中,我希望获得物化视图......但我正在使用Postgres.我喜欢将空间数据类型用于另一个项目,但是我将不得不做一个黑客,或者更改数据库来处理mySQL的坚持,即它们不是空的.我甚至不得不弄清楚如何禁用Oracle的事务一致性来处理OLTP上长时间运行的查询,这在mySQL中是没有问题的.
我通常可以针对给定问题围绕数据库的缺点进行编码,但问题的一部分在于为工作选择合适的工具 - 在当前项目中,我们浪费了数月复制的人工月数,因为我们是使用Postgres,他们在确实知道我们要复制的所有内容之前决定使用Slony-1.
...我认为这个问题就像'为什么没有更多的人在语言中使用特征x ' - 如果他们不是语言专家,他们可能不知道特征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年!他们甚至不想讨论你在问题中提供的子弹列表中的一个项目.
像这样的东西是我猜的原因.
| 归档时间： |
|
| 查看次数： |
2819 次 |
| 最近记录： |