与软件开发各个环节中对象技术的快速应用形成鲜明对比，对象数据库直到现在才开始逐渐被人们所接受。对象数据的迟缓行动原因有很多。

　　早期的对象语言没有考虑数据存储。程序在内存数据上工作，数据作为文件存储，当程序下次运行时数据也作为文件被读取。这种方法使得应用程序之间不可能共享数据，数据的恢复、管理、扩展几乎不可能。

　　目前在市场上已经有大量的面向对象数据库产品：Versant，Objectivity，Object Store，Gemstone等等。他们为面向对象的开发环境提供了相应的数据存储。这些产品满足了最初的热情，甚至这些产品被期望能够打造一个新的数据库市场——甚至可能成为市场的领袖。

　　但不幸的是，这些对象数据库出现时，关系型数据库供应商已经积聚了巨大的动力，并占领了大量市场份额。在标准的SQL接口下，访问关系型数据库的面向对象程序很容易写。相反，多数早期的对象数据完全不提供SQL接口，不适合任何查询应用程序。结果，对象数据库在商业上没有建立坚实的基础。他们在应用领域只创建了一个小市场来管理和存储复杂对象如CAD/CAM，电信业、多媒体、人工智能，模拟金融设备、病人诊治跟踪系统以及科学应用。

　　数据库市场从未特别关注过对象数据库，直到对象定义语言XML出现，这种情况才有所改变，促进了对象数据库的再次呈现，因为他们管理XML定义的数据是最合适的。使用XML，必然会提高存储复杂数据的需求，将进一步引发对象数据库的复苏。

　　03年9月份InfoWorld公布了一项开发员调查，其中有一个惊奇的结果，89.2%的被调查者说他们使用关系型数据库，52%的被调查者说他们使用面向对象或者XML数据库。当问及有关存储数据的类型时，40.2%的人说他们存储持久的对象，58.9%的人说他们存储XML数据，89%的人说他们存储关系型数据。Baroudi Bloor相信对象数据库比我们想象的用的更加广泛，随着需求的激增，将进一步扩大市场份额。

　　InfoWorld的调查还显示了面向对象的语言是新应用开发的主流选择。我们相信这些统计数字反映了当今开发员面临的困境。他们需要与他们一直使用的面向对象语言有更好协调性的数据库，但他们有需要关系型数据库所提供的查询能力。

　　关系型数据库——另一半是如何存在的

　　只要有程序，就会有数据。IT行业最早具有商业价值之一的就是数据管理。自动的数据管理意味着业务能够扩展、具有竞争力，没有它就不可能。所以毫无疑问机智的商业技术员很早把目光聚集在数据管理市场。在对象数据库产生之前的20年，E.F Codd博士提出的关系型理论找到了出路，开发出商业的关系型数据库产品。在80年中期，在IT领域有一个宗教式的信仰，认为数据的所有理论问题都已经解决，实践的问题也会随之解决。然而，很明显，事实并不是这样。

　　关系型数据库把数据存储在简单的两维表中，这是一种表达大量数据的有效方法，而且程序员也易于理解。关系型数据库使用SQL建立了一种标准的数据访问语言。关系型数据库有一个逻辑和物理形式清楚的结构，这种结构使得应用程序对数据结构是透明的，而且在很多商业应用程序中工作的很好。

　　然而，关系理论的基础之一是数据和使用数据的程序能够而且应该是相互独立的。这与对象技术的整个理念是不一致的。对象技术鼓励设计者使用对象而不是表来思考数据。对象和使用对象的方法是不可能彼此分开的。

　　如果把汽车作为一个复杂的对象来考虑。当你使用汽车时，你使用一辆完整的汽车，作为一个东西——一个对象来使用。与汽车相联系的有很多动作(也就是面向对象术语中的方法)。你驾驶汽车，进行换档，发信号，开车灯，等等。如果汽车是一个对象，这些动作就是对象的方法，他们对汽车而言是基础性的。这些动作独立于汽车的想法是荒唐的。当你把你的车停在车库，你把它作为一个东西来存储。而不是分别在车库中的某些地方存放方向盘，转换器，信号器，车灯。数据和它相对应的处理过程也不能而且也不应该被隔离开来。在对象数据库中他们是不分开的。

　　事实上，这两种观点各有优缺点。有些处理过程确实是独立于数据的。尤其是访问大量数据的查询操作。简单的查询就是根据一些标准来选取数据，而不关心数据是什么，也不用关心数据是如何被组织的，只要它能快速的被取出就可以了。查询是独立于数据的，但对象方法则不是。

对象-关系数据库

　　关系型数据库的供应商并没有忽视对象的出现。显然，规范复杂数据是没有意义的。举个极端的例子，如果你要规范一个位图形式的图像——是一系列的象素表示的——你最终要得出一个表，这个表的行是象素，并且主键的属性反映他们的顺序。很明显最好是把这个数据作为一个对象来存储。

　　他们提出了“对象-关系”数据库的创意，这个创意中保留了关系型数据库的结构，但允许关系表中的列含有一个复杂的对象。这些对象能够捆绑处理复杂数据的处理过程(一种存储过程)。并且SQL能够允许调用与关系型等同的“对象方法”。

　　这种方法是对数据关系理论的一种嘲弄，事实上，它完全忽略了这个理论，但又允许复杂数据(地图，矢量图，图表，甚至整个表格)被定义为一个项目存放在关系结构中。因此，这些功能被实现并商品化。Informix称它的嵌入过程为DateBlades，Oracle称之为Cartridges。

　　对象-关系数据库成为存储数据时对象数据库的一种替代方案，但根本的问题它并没有解决。对象-关系数据库还是受不匹配障碍的困扰。

　　对象数据库与关系型数据库

　　实践中，对象数据库相对于关系数据库有显著的优势。

　　他们能更快的运行事务处理程序

　　他们能够更有效的处理对象

　　他们能够提供更好的开发效率

　　他们能够管理更容易

　　在一些例子中，因为是性能方面的原因，用对象数据库能够替代关系型数据库。在不能存储复杂对象的大规模的业务处理程序中确实是这样的——也许有些人会认为这个必然是关系型数据库的领地。

　　对象数据库最大的性能优势是他们不必像关系型数据库一样在数据使用之前先连接数据。他们就以使用数据的方式存储数据，这就大大提高了性能。对象数据库能够使用缓存技术，这样就使得在请求数据时数据就已经存放在内存中了。对象数据库在抽取数据时几乎不需要进行优化。

　　但开发一个新的系统，处理复杂数据如文档、复杂图表、网页、多媒体等的需求不断增长时，这些需求对象数据库可以很好的满足。

当今面向对象的前景

　　在软件开发的各个方面使用对象技术的人群都在不停地增长。甚至在最后一个领域——数据库——尽管对象数据库还没有取代关系型数据库，这种增长也是十分显著的。InfoWorld报告说52%的开发员在使用对象数据库或者XML数据库(通常也是一种对象数据库)。还有一些选择混合形式的数据库，这种数据库能比较容易地使用对象结构。随着新应用程序开发过程中Web接口成为一个必不可少地部分，Web服务成为应用系统交互地一种可行的机制，构建一个面向对象的世界似乎是当今的现实。

　　03年9月的InfoWorld调查也显示了使用面向对象语言的程序员几乎无处不在。事实上，尽管有些人宣称使用C语言，但是面向对象的语言还是成为当今90%的程序员的选择。调查也显示了程序员比较喜欢基于Web的应用，易用的对象编程和脚本语言。随着越来越多的有着正规培训的软件工程师进入市场，面向对象技术将成为新应用开发的唯一选择。

　　也许关系型数据库将继续领导数据库市场，而对象数据库在市场上只占有一席之地。也许对象数据库将进一步提升市场份额，因为他们能够处理当今使用的复杂的数据。然而，我们认为还有其他的可能：数据库技术可能发展出一种真正的混合型产品，这种产品能提供关系接口和对象接口双重优势。我们知道这是有可能的。事实上，至少有一种产品，来自Intersystem的Cache，就是这样一个产品。(Cache数据库，描述他自己时，既不是说是关系型的，也不是说是对象的，而是后关系型数据库)。数据库供应商——不管他们的产品是属于关系型还是对象型——都会朝着这个方向前进的。

　　这种混合产品的方法包括给数据库提供一个映射层，程序员通过映射层访问数据库。映射层应该基于开发的标准以解决不匹配障碍问题。数据库的调用能够用SQL完成，也可以直接请求对象类或者类的集合。映射层能够把这些调用转换为对数据库的物理数据请求以抽取数据。这种方法将消除不匹配的障碍。

　　改变任何一种数据类型都是非常大的挑战。对象数据库需要快速索引能力，以从庞大的数据集中抽取数据。在这方面做得比较好的关系型数据库使用位图索引技术，但数据一旦更新，这些索引就需要重新建立。因为这个原因，很少有对象数据有这个功能。对关系数据库而言，他们需要提供更加灵活的物理数据结构。在发展过程中，关系型数据库倾向于在物理层使用表。他们需要放弃这种不灵活的限制，允许存储多种数据结构。数据库使用者将获得最大的收益。试想把对象数据库的优势和关系型数据库的优势整合在一起：

　　好的处理性能

　　复杂数据管理

　　管理简便

　　快速开发

　　灵活的查询功能

　　标准的数据访问接口

　　更好地适用于商业智能应用

　　这种混合产品使使用一个数据库引擎成为可能，并且所有应用只有一个数据定义集。Baroudi Bloor相信企业界需要混合式的数据库产品。供应商们必须放弃他们对关系数据库宗教式的倾向，转向更具优势的混合式的数据库，否则的话他们将陷于COBOL以及打孔卡片的深渊而不能自拔。