已经有人要求我对目标数据库模型与相关的数据库模型相比较的好处写一些东西。 坦白地说，我正犹豫不决是否按那种方式进行讨论。

　　我踌躇的原因在于我并未看见目标数据库(ODBMS)和相关数据库(RDBMS)的产品有竞争的方面。 相反，我把它们视为互补的选择，它们常常能在一个企业架构中共存得很好。 经常，这与多排的结构有关。下面举两个它们如何共存的两个例子：

　　基于网络的目录的内容是从多个存在源中提取出来的，以便在中间排中发布目录。目标数据库管理使用目录的权限。相关数据库和其它存储机制管理存在的源。通常，中间排目录是比较新的，在企业中以前是不存在的。

  　贸易或者拍卖系统只把当前交易或者竞拍的商品放在中间排中。目标数据库管理活动的交易和竞拍数据。相关数据库作为一个后段数据库或者从目标数据库中收到必要的历史数据的记录的数据库。通常，中间排交易或者竞拍系统是较新的，正在替代旧的，非DBMS的技术。

　　那么，你应该什么时候考虑使用ODBMS？ 多年以来，我一直告诉我的客户，他们只应该在对复合数据上有高性能的商业需求时考虑使用ODBMS。下面让我更进一步解释。如果你使用的是一种面向对象的编程语言，比如Java或者C++，又很完美的需要使用面向对象编程语言所提供的高级数据结构，还需要最高的性能，那么你应该考虑使用一种ODBMS产品。

　　有一些设计问题可以通过使用如表单、向量、哈希表、队列、堆栈等等数据结构得到很好的解决。在面向对象编程语言中，这些数据结构是可用或者可构造的。有时候，你需要使这些数据结构成为永久的数据结构。使用一个ODBMS产品，你可以不用经过任何的转换来存储任何可以想象到的数据结构。(如果你想一下，你会发现这是一个强大的重要的语句。)

　　因为在面向对象数据结构和ODBMS之间没有转换或者映射，性能也提高了。在面向对象数据结构和RDBMS之间的映射会降低性能。使用更复杂的数据结构，就会在性能方面有更多的下降。

　　能直接储存复杂的面向对象数据结构也会节省开发成本，因为相比较于用ODBMS，你使用RDBMS 可以写较少的代码。写较少的代码的原因是你只有一种数据模型要开发和维护。 此外， 你不需要写任何映射或者转换的代码，但是在你使用RDBMS里的不同的数据模型，而不是由面向对象编程语言提供的数据模型时，你需要写这些代码。

　　在面向对象程序语言和ODBMSs之间的紧密结合是你看到越来越多ODBMSs在嵌入式系统里使用的一个原因，但是我离题了...

　　因此，追溯到两个例子，这两个的数据结构都只在ODBMS 管理的中间排里存在。这些相同的数据结构在共存的RDBMS过程中不需要。在第一个例子中，来自现有的来源的数据的集合都只有在中间排目录中才需要。在第二个例子里，有交易和拍卖需要的数据结构，而后段数据库或者记录数据库不需要这些数据结构。

　　当你开发一个结构时，你不应该想当然认为你的数据库所需的全部都由某一种DBMS产品满足。另一种看待这个问题的方法是使用类比。难道你针对不同的应用总采用同一种工具吗？就像使用锤子来定螺丝钉是很困难的一样。或者，就这点而言，尝试用螺丝起子来敲钉子也是不现实的。

　　我们应该来看看这些基于结构需要的数据库产品，并针对每种工作采用最好的工具。这就说明了考虑在中间排结构中把RDBMSs 和 ODBMSs结合起来使用是有意义的。