31
A
回答
36
RDBMS保持流行的一个原因是，它建立的技术很好理解，并且具有多个供应商支持的标准语言（SQL）。它还有一些好的接口，如ODBC和JDBC，可以很好地连接不同的语言。稳定的API是保持技术优势的有力因素。
相比之下，OODBMS没有明确的模型，也没有标准语言，也没有标准的API。通过实施领先的供应商，甚至没有事实上的标准。
OODBMS概念可能表现比RDBMS + ORM更好。这完全取决于实施。但是，OODBMS并不能解决RDBMS擅长解决的同样一组问题。如果您具有数据管理解决方案强制的参照完整性和关系头，则某些数据管理任务更容易。 OODBMS模型中缺少这些功能（至少目前为止）。
博客上有很多噪音，关系数据库已经过时，但RDBMS仍然是绝大多数数据管理任务的最佳通用解决方案。
0
我认为这是如果不破不改变它的
的情况下。
关系数据库非常根深蒂固。
3
在（上周五晚上<摹>大词）
大多数企业一个字互操作性与RDBMS上运行原有系统的工作。如果他们要使用OODBMS，他们仍然需要访问RDBMS来执行某些功能。维护一种访问数据的方式比两种更容易。
当您在OODBMS世界拥有像Oracle和SQL Server这样的大公司，并在各种环境中获得可靠的性能时，那么您会看到更多使用它们的项目。
16
数据通常寿命更长，比程序更重要。所以，即使你今天开始一个绿地开发，你也必须考虑整体情况。 RDBM系统有更多的工具，流程和经验丰富的人员。除了能力计划，数据挖掘，报告，ETL，与其他数据源的整合等方面，您还可以思考一下，您的公司如何收购另一家公司，从而将所有关系数据纳入您的项目中。 RDBMS和相关工具是如此根深蒂固，被证明是有力的，所以我没有任何其他策略意义。 在一些小的利基，也许但不一般。
+7
“数据通常寿命更长，比程序更重要。” - 阿门。中间层来来去去，但数据永远存在。 – duffymo 2009-08-29 02:29:27
+1
OODBMS并不意味着与RDBMS绑定到特定于实现的存储过程的任何特定语言。 – 2010-07-30 11:18:45
+1
从理论上说，你是正确的，但实际上很少有人熟知的RDBMS实现，并且得到了工具，广大知识库和经验丰富的人员的支持。我的公司刚刚进行了企业合并，我们将数据从另一家公司的数据库导入到我们的数据库（进行了大量的转换，数据量和清理）。两家公司都使用Oracle，这使得事情变得更容易，当然比另一家公司使用了一个已知的数据库。 – softveda 2010-08-10 00:37:57
6
对象数据库对于代表几何图形等问题具有非常好的利基。 CAD系统，其中对象图的确可能非常深刻。在大多数关系系统中，JOIN性能会迅速降低大约7个表，因此CAD中的深度自引用结构在对象数据库中表现更好。
但重要的应用，如财务数据借给自己的关系表示。关系模型具有坚实的数学基础，SQL是一种成功和流行的语言。像银行，券商和保险公司这样的金融机构没有什么动力从RDBMS中转移出去。
20
我看到的最大问题是缺乏标准化。在RDBMS世界中，如果您知道SQL，那么您可以随意使用任意随机数据库。他们基本上都实现了它，只有很小的变化。我不知道一个现有的不执行SQL的RDBMS：您几乎可以互换使用“RDBMS”和“SQL”。
一个OODBMS最接近的事也许是OQL，这一直是一个彻底的失败。
没有数据库曾经实现过很多。几年前，我使用了一个相当不错的商业OODBMS，但是（截至2007年左右，主要版本为8或9），它甚至不支持通过名称查询对象。该手册简单地说，这部分OQL他们还没有得到。 （我不知道，但你可能已经能够下拉到本机调用做到这一点。）
大多数对象数据库我看到最近有本地语言的接口，而不是像OQL查询语言。例如，我使用的系统支持（仅限！）Perl和VB，IIRC。限制你的听众只能使用两种语言（或者像我们那样强迫他们写封装）并不是赢得朋友的方式。
正因为如此，有没有竞争，因此不容易的备份计划。如果您将数据置于MS-SQL中并且Microsoft停止支持它，则可以将数据转储到Postgres并移植查询，而不会造成太大麻烦。 （如果你有很多疑问，可能会做很多工作，但我并不怀疑你可以做到这一点，这是一种痛苦，但在技术上并不具有挑战性）。或者Oracle或MySQL或许多其他的商业并免费。
OODBMS不存在这样的事情：如果你使用的那个人肚子痛，或者他们对你没有用的方向，或者你觉得它缺乏你需要的关键功能，你可以只是将您的数据转储到竞争的OODBMS中并移植您的查询。相反，你正在谈论改变核心库并进行大规模的体系结构变更。所以现实地说，你仅限于一个你真正信任的商业OODBMS（你能说出一个名字吗？），或者是一个开源的OODBMS，当事情变糟时，你信任你的团队维护它。
如果这听起来像FUD，对不起，我不打算说。但是我一直在那里，并且从项目管理的角度来看，即使编程环境可以很美妙，我也会犹豫回去。另一种思考它的方法是：看看今天多么流行的函数式编程，尽管它是一个好主意。 OODBMS就是这样，但更糟的是，因为它不仅仅是你的代码，还有你的代码和你的数据。我很乐意今天在Erlang开始一个重要项目，但我仍然犹豫使用OODBMS。
面向对象数据库厂商：改变这一点，你需要make it easy to leave you for your competitors。您可以挖掘OQL并实际实现它，或者在API级别（如ODBC）或任何其他位置执行该操作。即使是标准的转储格式（使用JSON？），以及用于将数据导入/导出到多个OODBMS的工具，也是一个很好的开始。
4
对于trival示例OODB和RDB可能会有很大的不同。特别是如果您使用的数据量足够小，您可以一次性将所有数据全部读入内存并一次写出所有数据。但最终OODB需要以非常类似RDB的格式保存数据 - 它们并没有太大的差别。
考虑可能在应用程序中使用的对象的任意图形。每个对象可能被其他几个对象引用。保存对象图形时，您不希望每次引用对象时都重复保存对象。首先，如果你有任何一种循环或自我引用，你的保存对象方法会进入无限循环。但在一般情况下，这是浪费空间。相反，任何重要的数据存储都需要为每个要存储的对象（一个关键字，通常是RDBMS中的代理关键字）声明唯一标识符。引用它的每个其他对象保存对象类型和键，它不会重复保存整个对象。所以在这里我们已经在我们的非RDB对象存储中重新创建了外键。
接下来假装我们要存储与另一个对象（B）相关的对象列表（A1，A2，A3 ...）。我们已经确定我们将存储密钥而不是将对象本身保存两次。但是，您是否将键存储在对象B上的对象A1，A2，A3 ...上，或者是否将键存储在对象B上？如果您以第一种方式存储它们，并且您拥有所需的全部A，则可以快速获取相关的B。第二种方式是相反的。但无论哪种方式都是单向交易。如果你想查询你存储的内容和你的对象存储为XML或JSON的相反情况，那么通过大多数不相关的信息来解析每个文件中的密钥是非常低效的。将它们以每个字段分开的格式（比如表格中的列）存储起来会不会更好？
在多对多关系中，或者需要在两个方向上查找大量对象的情况下，此策略变得非常低效。唯一的高性能解决方案是创建一个帮助对象来存储关系，每个关系有一个文件，这样该文件由A的键和B的键组成，以便快速查找它们。我们刚刚重新创建了交叉引用表。
带有列，唯一标识符（键），交叉引用表的表格......这些是存储对象的基本需求，以便可以高效地检索对象。嗯...这听起来像什么熟悉的？关系数据库提供了这个功能。此外，多家供应商已经竞争了数十年，以提供最快速的数据存储和检索功能，并提供备份，复制，群集，查询等最佳工具。这对于一种可与之竞争的新技术来说非常重要。最后，我说的是RDBMS基本上是解决高效对象存储问题的一个非常好的解决方案。
这就是为什么像Hibernate这样的东西存在 - 把面向对象的接口放在高效的RDBMS存储系统上。当你看到其他类型的存储的真正出色的是不同的问题领域：
- 对于任何类型的非结构化文档存储（博客，源代码控制，或任何不能映射到行和列），各种NoSQL数据库是理想
- 保留一个易于查询但有意义的更改历史记录（如源代码控制中的差异）在RDB中并不十分漂亮。像Datomic这样的东西可能会在这里形成新的领域。
- 任何时候你的对象图是简单的还是小的，数据库的开销都不是必需的。
OODBs不能比RDBs表现得更好，因为它们没有根本的不同。
RDBs在这里留下来，因为以节省空间和检索的节省空间和节省时间的方式保存大型对象图，并且还具有容错能力并且有一定的数据完整性保证，这是RDB设计为首先解决。这就是为什么JPA和Hibernate在这里保持原样 - 因为它们弥合了对象和关系数据模型之间的差距。易于在内存中操作的对象模型，以及持久性的关系。
“如果它没有被破坏，不要改变它”是如此愚蠢......为什么要做更好的事情，或者开发软件的速度更快，是一件坏事。当我改变它时，我的最后一台计算机没有损坏，只是慢！争取更好，更高效的解决方案是我作为开发人员的目标。 – billy 2012-04-05 11:34:34