年前，微软宣布了称为Windows开放服务架构(WOSA)的技术战略。WOSA 的精华是开放式数据库连接(ODBC)，它是Windows平台提供一套通用数据库存取服务的模型，而数据库供应商为他们的产品提供适配器。所以，Windows应用能避免为数据源编写的适配器的工作，相反地借助标准化的ODBC架构存取数据，能集中精力做一些有用的事情。在Windows的其他地方也有同样的思路在起作用。例如，统一的打印机和调制解调器访问。并且微软做了一个极好的工作以抵销各种各样的网络之间的差别。Windows网络服务可在TCP/IP、IPX/SPX和NetBEUI上以相同的方式运行，因为平台在一个中间层上抽象这些协议的差别。

“微软只是一个商业的公司，”Linux 社区喜欢这样看。这种说法有很多真实性，但是真实的故事却要复杂的多。当微软将WOSA风格的抽象引入核心服务，它是作为改革者出现，而Unix/Linux更象是蹒跚学布的原始人。

我现在为什么提起这个问题？上星期我在做一个Zope/Python的应用需要与一个SQL数据库通信，我从Godfly开始，它是一个全部用Python编写的轻重量级别SQL数据库引擎。
Godfly确实很灵活，并且它是Zope内置的数据引擎的一种解决方案，你可以立即用于原型设计，但是一个置于内存的基于脚本语言的SQL引擎将无法处理我的项目需求，而且, 与Godfly一样，它只是SQL的一个子集--例如无ALTER TABLE命令，因此现在正是把Zope挂到一个传统的SQL引擎上的时候了。

在我家庭实验室用NT工作，是因为ODBC不用动太多的脑筋。Zope提供一个称为ZODBCDA适配器产品，它可在数秒内安装，并且立刻让你的Zope环境存取所有系统被设置与之通信的ODBC数据源。这些可能是经由Jet引擎存取得的本地.MDB文件，或者是Oracle、SQL服务器或任何其他数据库的本地或远程实例。

在我的应用建立原型后, 现在是运用它的时候了，运用平台是Linux和MySQL。Zope本身在Windows上和Linux上同样运行，我已经发现这点，因此我不期望有任何麻烦，但是因为我想当然地相信ODBC数据源的中间性，但悲惨的事实中间性还远离Linux世界的常规。特别是Zope和MySQL，你得：

找到并构建将Python捆绑在MySQL客户库的Python扩展，然后构建Zope包装程序以事适配这个SQL扩展。

我以前从来没有构建过Python，我试一了试但失败了。我肯定有其他读者尝试并且成功，我为它们鼓掌，但难道你不是花时间用Zope做些有用的事情，而非将自己处于一个你能开始做事的境地吗？生命太短暂了。那天的结束后，我从Python回到了Perl，并且让我的应用很快运行起来了。为什么呢？Perl的类ODBC驱动程序管理器DBI已经在我的机器上安装好了，它是DBD::mysql－MySQL适配器。总的来说，由于DBI设计师Tim Bunce和一大批真正的驱动程序编写者的出色工作，Perl用才分享着ODBC的许多好处，但是你没有看到这种景象有什么不对吗？投入Perl DBD::mysql的劳动力竟没有一个人继续进行Python、PHP、Tcl或其他要与MySQL通信的应用的开发，这些环境的每一个都必须定义它自己的数据库抽象层，然后希望鼓励
开发者建立全部数据库的适配器。有时它会发生，但通常不是，结果是五花八门的数据源。在数据库新闻组我问了：为什么坚持应用在一端而数据库在另一端这种疯狂组合的泛滥，所有这些都必须以成双成对的方式连接吗？注意在Windows中，仅需要一个Zope ODBCDA，它让你进入缤纷世界。我确实希望Linux/Unix也能如此。

看Perl DBI的例子。它是一个有力的尝试，证明驱动程序管理器/数据适配器模型是必要的。
，但仅仅是对于Perl。那么Python来了，必须开发一个Python的DB-API，并希望得到广大的数据库开发者们支持它，就像Perl开发者们支持其“通用”API一样。

我断言如果你把投入在针对Unix数据库的Perl、Python、PHP、Tcl或其他只有上帝知道的东西的努力全部加起来，大大超出得到一个完备的由这些环境和数据库供应商曾经支持的类ODBC模型。

事实上，Alastair Sherringham已经说过，这些问题正在被解决，他提交给我们给一些URL记录了各种各样的 ODBC-for-Unix 努力：

Brian Jepson's FreeODBC pages：http://users.ids.net/~bjepson/FreeODBC/
The Unix ODBC project：http://www.unixodbc.org

事实上我听到这些好多年了，但是我不得不感到惊讶：

与4年前相比，通用的数据库抽象层为什么今天感觉不到进一步成为Linux的标准部件？

我想知道是否开放原代码的进程－至少当到目前为止我们看见它－并为加快认同并取得这种战略目标。

我不想批评或轻视这些不懈的努力，我只是真诚地想知道怎样做才能使在Linux上的多厂家数据库存取能像在Windows上那样直截了当。

另一个更深入的有趣URL：

http://www.openlinksw.com/iodbc/

在1999年1月，OpenLink软件公司宣布它将管理以iODBC(independent ODBC)而出名的开放原码工程，它原来是Ke Jin完成的微软ODBC驱动程序管理器的一个移植版本。因为OpenLink软件公司是一个有丰富数据库技能的公司，这听起来前景大有希望，也许Openlink的工作最终将推动Linux数据库存取技术。为了知道更多，我打电话给了Openlink的总裁首席执行官Kingsley Idehen。

Jon(笔者，下同):我无法搞清所有这些Unix ODBC行动的脉络。
Kingsley：有3个主要的线索。首先是iODBC，是由Ke Jin启动的公开原代码工程，这是我们支持的一个。然后有Merant ODBC SDK，它是Merant(Micro Focus和INTERSOLV合并而成)从Visigenic继承的。该ODBC for Unix产品基于微软许可的代码并移植到Unix，它不是公开原代码的。最后有unixODBC，它也使用 iODBC并且增加图形用户界面以支持驱动程序更友好的安装和配置。

unixODBC使用另外一个ODBC驱动程序而不是iODBC，这样做是因为他们想要一个ODBC 3.5驱动程序而不是ODBC 2.5，他们宣称将走得更远，为此开发另一个unixODBC项目改进iODBC。

jon：为什么ODBC的推动力来自微软而非Unix社区？

Kingsley：不是的。SAG CLI(SQL Access Group Call-Level Interface-SQL存取组调用层接口)最早(大约1990)由Unix数据库供应商－Oracle、Informix等提出的，微软以后才加入。但是微软领悟了，而Unix 社区从来没有，一个图形用户界面能如此扩大观众的视野。用