应用设计中的针对数据库的开放性考虑

应用设计中的针对数据库的开放性考虑

 

我经常看到，人们选择艰难的道路还有一个原因。这还是与那种观点有关，我们总认为要不遗余力地追求开放性和数据库的独立性。开发人员希望避免使用封闭的专有数据库特性，即使像存储过程或序列这样简单的特性也不敢用，因为使用这些专有特性会把他们锁定到某个数据库系统。这么说吧，我的看法是只要你开发一个涉及读/写应用，就已经在某种程序上被锁定了。一旦开始运行查询和修改，你就会发现数据库间存在着一些微小的差别（有时还可能存在显著关异）。例如，在一个数据库中，你可能发现SELECT COUNT(*) FROM T查询与两行记录的更新发生了死锁。在Oracle中，却发现SELECT COUNT(*)绝对不会阻塞写入器。你可能见过这样的情况，一个数据库看上去能保证某种业务规则，这是由于该数据库锁定模型的副作用造成的，但另一个数据库则不能保证这个业务规则。给定完全相同的事务，在不同数据库中却有可能报告全然不同的答案，原因就在于数据库的实现存在一些基本的差别。你会发现，要想把一个应用轻轻松松地从一个数据库称植到另一个数据库。这种应用少之又少。不同数据库中对于如何解释SQL（例如，NULL=NULL这个例子）以及如何处理SQL往往有不同的做法。

 

在我最近参与的一个项目中，开发人员在使用Visual Basic、ActiveX控件、IIS服务器和Oracle构建一个基于Web的产品。他们不无担心的告诉我，由于业务逻辑是用PL/SQL编写的，这个产品已经依赖于数据库了。他们问我：“怎么修正这个问题？”

 

先不谈这个问题，退一步说，针对他们所选的技术，我实在看不出依赖于数据库有什么“不好”：

l       开发人员选择的语言已经把他们与一个开发商提供的一个操作系统锁定（要想独立于操作系统，其实他们更应用选择Java）。

l       他们选择的组件技术已经将他们与一个操作系统和一个开发商锁定（选择J2EE更合适）。

l       他们选择的WEB服务器已经将他们与一个开发商和一个平台锁定（为什么不用Apache呢？）。

所选择的每一项技术都已经把他们锁定到一个非常特定的配置，实际上，就操作系统而言，惟一能让他们有所选择的技术就是数据库。

 

暂且不管这些（选择这些技术可能有他们自己的原因），这些开发人员还刻意不去用体系结构中一个重要部件的功能，而美其名曰为了开放性。在我看来，既然精心地选择了技术，就应该最大限度地加以利用。购买这些技术你已经花了不少钱，难道你想白白地花冤枉钱吗？我认为，他们一直想尽力发挥其他技术的潜能，那么为什么要把数据库另眼相看呢？再者，数据库对于他们的成功至关重要，单凭这一点也说明，不充分利用数据库是说不过去的。

 

不过接下来，你把所有应用逻辑还有（更重要的）安全都放在数据库之外。可能放在访问数据的bean中：也可能放在访问数据的JSP中；或者置于在Microsoft事务服务器（Microsoft Transaction Server，MTS）管理下运行的Visual Basic中。最终结果就是，你的数据库被封闭起来，这么一来，数据库已经被弄得“不开放”了。人们无法再采用现有技术使用这些数据；他们必须使用你的访问方法（或者干脆绕过你的安全防护）。尽管现在看上去还不错，但是你要记住，今天响当当的技术（比如说，EJB）也会成为昨日黄花，到了明天可能就是一个让人厌倦的技术了。在关系领域中（以及大多数对象实现中），过去25年来只有数据库自己傲然挺屹立。数据前台技术几乎每年一变，如果应用把安全放在内部实现，而不是数据库中实现，随着前台技术的变革，这些应用就会成为前进道路上的绊脚石。

 

……

 

人们总是不遗余力地去争取数据库独立性和完全的开放性，但我认为这是一个错误的决定。不管你使用的是什么数据库，都应该充分地加以利用，把它的每一个功能都“挤出来”。不论怎样，等到调优阶段你也会这样做的（不过，往往在部署之后才会调优）。如果通过充分利用软件的功能，会让你的应用快上5倍，你会惊讶地发现，居然这么快就把数据库独立需求抛在脑后了。

 

摘自 Thomas Kyte 《Expert Oracle Database Architecture》