这就是问题所在。只考虑一个原因，你认为为什么OODB会失败，或者为什么现在很多系统仍然使用关系数据库。
答案 0 :(得分：24)
主要原因是SQL。能够在应用程序之外的其他上下文中使用来自数据库的数据非常有用，并且通常对于对象数据库，数据以不容易查询的格式存储。例如，对于关系数据库，数据可以成为数据仓库的一部分，或者只是由sys管理员等查询。
答案 1 :(得分：21)
我们可以不止一次回答吗？另一个原因是关系数据库在数学方面有很强的基础：从关系的定义到正常的形式，理论是坚如磐石的。确实，关系模型不能很好地映射到OO，但恕我直言，该模型的好处和稳定性超过了映射问题。
答案 2 :(得分：13)
我认为这是因为“对象数据库”正在解决（几乎）没有人真正拥有的问题。对于对象图的简单持久性，大多数OO环境中内置的序列化“足够好”。如果您想对数据的子集进行复杂的操作，那么关系数据库和SQL是完美的选择。
除了一些边缘应用程序（巨大的对象图不能保存在内存中，但关系不能很好地简化RDBMS使用），实际上不需要这些工具。
答案 3 :(得分：11)
仅仅因为OODB不是主流，我们仍然应该考虑他们所拥有的成功。 Cache和Zope都被广泛使用（相对），但某些标准会被认为是成功的。
也许OODB没有取得显着成功的最大原因是混合对象关系系统的成功，它占据了OODB的大部分潜在市场份额：PostgreSQL和Informix。
我知道这并没有直接回答这个问题，但我认为这是等式的一部分。但总的来说，我认为动力和支持关系数据库的根深蒂固的思维过程使人们难以转换。目前，数据库专业几乎完全是在关系理论方面进行培训，使您的数据库专业人员对避免OODB非常感兴趣，学术界几乎专门为关系人员教授DB理论。
直到大型的企业DBA和主流教授以及课程和超出开发人员的人员准备管理OODB我觉得无论发展方面有多好，都不太可能看到大众吸引力。
答案 4 :(得分：8)
除了成熟和吸收的问题之外，从哲学的角度来看，OODB似乎是有益的或是OO应用。不必为初学者维护那个映射层;）
但是看，如果你没有进行域驱动器设计并使用对象作为数据对象，就像你的存储过程一样，那么你真的不会得到它;）
答案 5 :(得分：5)
RDBM（建立在强大的理论基础之上，已经在市场上存在了更长的时间，在许多情况下可以比OODB更忠实地建模数据，可以被比OODB更多的DBA使用）。这是关系元组形式的一个原因。
答案 6 :(得分：3)
如果我可以放大Phil的观点：SQL的标准化。 OODB尝试过像OQL这样的查询语言，但它们似乎从未遵循真正的标准。此外，查询语言的质量也令人怀疑，可以说是由于缺乏标准化。标准促进竞争，产生质量。
答案 7 :(得分：3)
一个原因是数据库是关于数据的，而对象是关于结构和算法的。一旦获取数据并将其嵌入到类中，就可以表征静态结构中的关系和操作。另一方面，数据库是关于将数据非结构化为一堆原子表的实例，这些实例可以重新组装成不同的结构（通常是类），而不会干扰原子的完整性。
数据库有点类似于hexahexaflexagons。
答案 8 :(得分：2)
那个和o / r-mappers。通过它们，真正的OO-DB的差异变得更小，而上述好处仍然有效。
答案 9 :(得分：2)
技术知识不具备昂贵的技术决策。使用关系数据库的公司雇用了许多感受到OODB威胁的人，因此会避免了解它们。
答案 10 :(得分：1)
我认为有两个哲学原因。
首先，人们传统上倾向于将持久性与实际功能分开。一旦你剥离了一个物体的“生命”远离它并将其主要用于持久性，它就会变成一个记录，然后就会把它当作一个“没有生命的”数据对象。
接下来，当人们想到大量非常相似的东西时，他们开始将它们视为表而不是对象。
我认为O / R的区别开始消失。例如，我使用hibernate将非常复杂的类层次结构转储到MySQL数据库中。但是，我没有为我的项目编写性能关键的东西，所以我确信它没有有效地完成。
答案 11 :(得分：1)
OODB采用缓慢的原因很大程度上取决于使关系型SQL数据库更受欢迎和/或更合适的几个关键因素。 虽然纯面向对象的数据库现在处于克服关系模型的许多缺点的状态，但是缺少一些关键部分。
对于他们而言，他们往往缺乏对中央数据库管理的支持，尽管这种情况在各种产品中都得到了迅速纠正。
第二个原因是很少有系统实现标准查询语言，而是依赖于编程语言或专用查询语言来检索和操纵存储中的数据。如果他们必须在用于基于NoSQL的解决方案的程序员的完全不同的思维模式之上学习新的查询语言，那么对于许多人来说，这是一个显示阻止。 最重要的是，大多数基于SQL的/ Relational数据库现在都支持面向对象的设计，而且我们有像ORM这样的包装器，许多人用它来“绕过”关系数据库的问题，而这些问题在所选择的编程语言中并不容易获得。 / p>
但这些问题主要存在于企业环境中。 作为小型设备中的嵌入式数据库，作为网站存储以及航空航天等领域，它们已经变得非常流行，并且在许多情况下完全取代了对常规关系数据库的需求。
谁知道未来会怎样？
答案 12 :(得分：0)
大多数语言提供的序列化使您可以展开Object属性，从而轻松地将它们存储到RDBMS中，类似地检索对象不是一个大问题。仍然缺乏广泛而坚实的基础，阻碍了OODBMS的实施。
我目前正在考虑将此作为我的Master Thesis项目，为OODBMS提供一个通用框架，该框架支持几乎所有现在常用于RDBMS的组件，从而提供非线性结构化DBMS。在学习的过程中，我遇到了一个名为db4o的项目，这是一种仅使用OODBMS for Java和.net的方法（实现），因此这可能是所有类型的平台和语言缺乏通用性的另一个原因。
答案 13 :(得分：-1)
我认为这是因为像甲骨文这样的大家伙一直在投资关系数据库，而面向对象的运动正在获得动力......如果甲骨文/微软大力投资，它们可能会成为主流...这似乎不太可能因为他们没有充分的理由这样做......它会简化许多程序员的生活......但“让程序员生活更简单”对他们来说不是一个很好的商业目标！