请将注意力再次集中到图1。在图1的最后一环，可以看到BDE连接到了具体的数据库。其实，在这一环中，也是有几个层次的。理论上来说，BDE可以连接任何类型的数据库。对于一些比较简单的数据库，例如ASCII（纯文本型的数据库）、dBase以及Delphi自己的Paradox，BDE可以直接访问。另外它也可以通过一些相应的驱动，访问特定的数据库，例如通过DAO访问Access数据库。对于不能直接支持的数据库，BDE还可以连接到ODBC，通过ODBC进行访问，虽然这样效率比较低。
这种性质决定了BDE是一个相当庞大的东西。使用了BDE的Delphi程序，必须有BDE才能工作，所以必须同BDE一起发布。这样往往造成这样一种情况：只有几百K的应用程序，在将整个BDE加入之后，体积将近10M！这对于以轻薄短小为长的文件型数据库，简直是一个致命的弱点。而且由于BDE要兼容太多的数据库，本身也有不稳定的毛病，往往出现令人头疼的问题。同时，通过安装程序安装BDE驱动和设置数据库别名也是一件很麻烦的事情，这一切使得BDE在Delphi程序员中很不受欢迎。在网上的Delphi技术论坛里，经常可以看到对BDE的一片咒骂之声……那么，有什么办法可以绕过BDE吗？
有的。目前来说，至少有以下三种方法：
(1) 使用第三方构件。
Inprise自己也很早就意识到了BDE的问题，虽然他们不肯放弃BDE，但是从Delphi3起，仍然对程序员提供了一个不错的选择：创建自定义的DataSet构件。Delphi的开发者们把所有有关BDE的东西从TDataSet类中移走，放入了新的TBDEDataSet类（TBDEDataSet类是TDataSet类的子类）。TDataSet类被重新构造，其核心功能被虚拟化。因此，你只需要从TDataSet类派生一个自己的新类，并重载一些指定的虚拟方法（用以访问具体的数据库），你就可以得到一个自己的DataSet构件。它与BDE完全无关，但可以象Delphi自己的DataSet构件一样被使用，例如，访问其Fields属性，乃至与Delphi的Data-Aware构件一起工作！
于是出现了大量的第三方构件，它们可以访问某种特定的数据库。下面是一些比较常见的访问文件型数据库或ODBC的第三方构件：
表2名称支持的数据库类型DiamondAccessHalcyonDBase/FoxproApolloDBase/FoxpromODBC任何ODBC数据库ODBC Express任何ODBC数据库
这些控件被广泛使用，在国内，就作者所知，财智家庭理财软件使用了Diamond，而“追捕”（一个显示指定IP的地址位置的共享软件）使用了Halcyon。在使用这些第三方构件之后，软件终于可以“轻装上阵”，再也不用为BDE头疼了。
(2) 使用ADO。
在Delphi5中，Inprise终于提供了一个比较彻底的解决方法，那就是ADO构件。从原理上来说，ADO与上述的第三方构件并无多大区别，只是它是Inprise官方开发的；同时，它连接的不是某个具体的数据库，而是微软提供的ADO对象。
ADO（ActiveX Data Object，ActiveX数据对象）是微软提出的新标准，从理论上来，能够支持任何类型的数据库（甚至包括流式数据）。微软力图将它树为新的统一数据库接口，吹嘘了它的许多优点。Inprise一直是微软不共戴天的竞争对手，对微软的标准嗤之以鼻（BDE即是一例），但是由于种种原因，Inprise终于承认了ADO。平心而论，用ADO来取代BDE的确是一个不错的解决方案，而且在Delphi中使用ADO也相当方便。从形势看，ADO应该是未来的方向。但是，ADO本身也是相当大的。
(3) 从最底层开发一个完整的数据库引擎。
这是最彻底的办法。彻底抛弃Delphi的数据库支持，从字节开始，开发自己的数据库。这种方法有其好处：第一，不用考虑兼容性问题，例如不用去考虑用户的数据库文件是Access 97格式还是Access 2000格式的；第二，可以在性能上达到最充分的优化，因为不需要通过任何通用接口，而是直接对磁盘文件进行操作，这对于一些对性能要求苛刻的程序是很有用的；第三，能够最大限度地减少冗余代码，因为这种数据库往往是特定格式的，而且只需要执行一些特定的操作，访问代码当然要比通用数据库精简得多。但这种方法的负面问题也显而易见，那就是庞大的工作量。再简单的数据库也是相当复杂的，从最底层实现一个完整的数据库引擎，往往需要几千行代码，以及耐心和经验。
虽然听起来有些极端，但这样做的也不乏其人。著名的Foxmail就是使用了自定义的数据库格式来储存信件、地址本等有关信息。另一个共享软件“电子书库”也使用了自定义的.srm格式。作者开发的iCompanion（网络伴侣）也是使用自定义格式来储存网络记录的。
限于篇幅，这里就不再对具体的程序进行详细的分析了。要补充的一点是，作者曾使用Diamond开发过Rich Explorer，这是一个专门用于浏览著名的大富翁论坛的离线数据库（Access格式）的阅读器。在作者的主页上，可以找到Rich Explorer的全部源代码，它完整地展示了一个使用第三方构件访问特定数据库的程序（没有使用Data-Aware控件），代码也比较简单，适合于初学者分析，有心的读者不妨作为参考。
2.2 C/S型数据库
C/S（Client/Server，客户机/服务器）型数据库是当前数据库应用的主流。
与文件型数据库不同的是，C/S型数据库应用程序由两个部分组成：服务器和客户机。服务器指数据库管理系统（Database Manage System，DBMS），用于描述、管理和维护数据库的程序系统，是数据库系统核心组成部分，对数据库进行统一的管理和控制。客户机则将用户的需求送交到服务器，再从服务器返回数据给用户。
C/S型数据库非常适合于网络应用，可以同时被多个用户所访问，并赋予不同的用户以不同的安全权限。C/S型数据库支持的数据量一般比文件型数据库大得多，还支持分布式的数据库（即同一数据库的数据库位于多台服务器上）。同时，C/S型数据库一般都能完善地支持SQL语言（所以也被称作SQL数据库）。这些特性决定了C/S型数据库适合于高端应用。
常见的C/S型数据库有著名的Oracle, Sybase, Informix, 微软的Microsoft SQL
server, IEM的DB2，以及Delphi自带的InterBase，等等。
C/S型数据库涉及到非常多的高级特性，是Delphi中，也是整个计算机领域中最大的应用之一。由于本期附录中已有专文讨论，本文就不拟详细介绍了。
随着技术的不断更新，C/S型的结构也开始逐渐被多层（Multi-Tiered）数据库模型所取代。
上面说到，C/S型数据库程序由服务器和客户机两个部分组成，因此被称为双层（two-tiered）模型。文件型数据库程序则被称为单层（single-tiered）模型。单层模型是最原始的数据库模型。后来程序员们将数据库转移到一个强大的中央服务器上，让它为多个功能较弱的客户机提供服务，这样双层模型出现了。双层模型在金融、电力、通信等领域被广泛使用，极大地推动了网络数据库的发展。但是，双层模型也逐渐暴露出其不足的一面。在这种情况下，出现了三层模型：应用程序中的数据模块部分被分离出来，转移到一个单独的服务器上，成为独立的一层。三层和三层以上的模型，统称为多层模型。
` 简言之，三层模型由以下三个层次组成：
客户机-应用程序服务器-数据库服务器
用户的请求首先通过客户机向应用程序服务器发出，应用程序服务器再向数据库服务器发出具体的数据访问命令（一般是SQL），数据库服务器返回的数据被应用程序服务器重新组织之后返回给客户机。
可以看出，三层模型是双层模型的扩展。目前我们无需了解三层模型的所有技术细节，以及它对于双层模型的优势
上一页 [1] [2] [3] [4] [5] [6] [7] [8] 下一页
 网友评论：（评论内容只代表网友观点，与本站立场无关！） |
- GOOGLE广告
阅读排行
|
