为什么ODBC不是Linux的一个标准特征？

　　年前，微软宣布了称为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 Aclearcase/" target="_blank" >ccess Group Call-Level Interface-SQL存取组调用层接口)最早(大约1990)由Unix数据库供应商－Oracle、Informix等提出的，微软以后才加入。但是微软领悟了，而Unix 社区从来没有，一个图形用户界面能如此扩大观众的视野。用户友好的安装、配置和测试是微软实现的特征，它帮助微软取得巨大的商业成功。
　　
　　Jon：为什么iDOBC仍未没获得这样的吸引力？
　　
　　Kingsley：问题是它在GNU GPL下发行，不是LGPL(原Library General Public License, 现在是Lesser General Public License，见http://www.gnu.org/copyleft/lesser.html)。在我们开始了支持iODBC时，我没理解其中的差别。但是当我们发行在iODBC上的Virtuoso时(Openlink 商业通用数据库产品)，人家告诉我：“Kingsley，iODBC是GPL'd，因此你必须也让人家得到Virtuoso的源代码”。用LGPL，你能发行连接到公开原代码库的一个商业产品。既然iODBC是在LGPL下，我希望我们除掉一个巨大障碍并将看到丰富的iODBC工具和Linux应用的崛起。
　　
　　Jon：unixODBC呢？
　　
　　Kingsley：我与Richard Stallman正在讨论这个LGPL问题，unixODBC作为一个LGPL项目启动，并且两个主要领域取得进展。首先，不论iODBC是没有GUI的一个传统Unix应用软件，Unix ODBC旨在用Qt做出图形界面，并且与KDE集成。第二，Unix ODBC从ODBC 2.5进展了到ODBC 3.5。
　　
　　Jon：你的iODBC项目当前计划是什么？
　　
　　Kingsley：我们准备发布符合ODBC 3.5的一个iODBC的版本，但它也与ODBC 2.5是向后兼容的，并且我们增加图形界面部分，但是我们正在用GTK开发，因此他们将工作在KDE和GNONE。在大约一两个星期内，你将看见它的beta版。希望关注unixODBC的人们能认识到仍然有很多的工作要做。为了使iODBC确实出色，我们将开发一个包括Gator(ODBC 测试工具)和支持跟踪的驱动程序管理器的最佳实现，因此人们可以评价和体是其应用。
　　
　　Jon：你为什么正在做这项工作？
　　
　　Kingsley：我们相信质量而非市场炒作。Linux是一个高质量厂品，我们想要看它在黑客和商业社区都取得成功，这意味必须有一个通用数据绑定层，在它上面构建桌面/终端用户和服务器者解决方案。很自然这绑定层的候选者是ODBC驱动程序管理器，这一层也显然需要公开原代码。归根结底Linux、UNIX和WIN32将驻留大量的遵从ODBC的工具，只要我们不断地开发高效ODBC驱动程序，我认为我们的商业目的将也仍然是保持完整。
　　
　　ODBC驱动程序管理器(DM)应该是置入OS的基础结构技术(就像Windows下的ODBC那样)。因为Linux是有争议OS，ODBC DM必须公开原代码，但是要有正确的许可证(LGPL而非GPL)。
　　
　　Jon：最后还有的什么想法？
　　
　　Kingsley：总的说来，非Windows社区没能看到或欣赏SQL数据的基本重要性。这是世界上的最不可思议的事，看看这个社区是由一些你能在任何地方找到的技术尖子和绝顶聪明的人组成。微软理解地最好的是数据中心化，使得一个平台同样推动应用开发人员和终端用户等。我正在期望Linu、Unix和其他非Windows 社区有一天能理解这些。我对这项努力的贡献是我对的iODBC公开原代码的项目的支持。
　　
　　Linux社区的人们没能看见数据的重要性。它是在地球上最不可思议的事情。微软理解地很好的，在今后，正式数据绑定使得一种平台推动商业用户。微软领悟了，Linux却没有。
　　
　　

原文转自：http://www.ltesting.net