关于Delph连接数据库原理（2）

这段代码访问了Table1中当前记录的名为Last Name的字段，该字段的类型为String。

事实上，Data-Aware构件就是通过访问DataSet构件的Fields属性来使用数据的。弄明白了这一点之后，你自己也可以尝试改写一个常规的显示构件，使之具有Data-Aware的性质。其实，大多数使用Delphi的数据库高手并不喜欢使用Data-Aware构件，因为Data-Aware构件远不用常规的构件来得灵活。DataSet构件除了Fields属性之外，还具有数目众多的特殊属性、方法和事件，足以应付从小型文本数据库到大型网络数据库的所有应用。本文不拟一一讨论它们，如果读者能将它们的运用烂熟于心的话，可以说应付数据库编程就不会有多大问题了。

请将注意力再次集中到上面的结构。在上面的结构的最后一环，可以看到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的第三方构件：
Diamond 支持的数据库类型 Access
Halcyon 支持的数据库类型 DBase/Foxpro
Apollo 支持的数据库类型 DBase/Foxpro
mODBC 支持的数据库类型 任何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控件），代码也比较简单，适合于初学者分析。