为什么关系数据库比面向对象的数据库更常见？
如果面向对象编程范例如此广泛，我们不应该看到很多OODBMS吗？它们不会比RDBMS + OR / M表现更好吗？
答案 0 :(得分：37)
RDBMS保持流行的一个原因是它已经建立了技术，很好理解并且拥有多个供应商支持的标准语言（SQL）。它还有一些很好的接口，如ODBC和JDBC，可以很好地连接不同的语言。稳定的API是保持技术占主导地位的重要因素。
相比之下，OODBMS没有明确的模型，也没有标准语言，也没有标准API。通过领先的供应商实施，甚至没有事实上的标准。
OODBMS概念可能的性能优于RDBMS + ORM。这完全取决于实施。但是，OODBMS也无法解决RDBMS擅长解决的同一组问题。如果您具有数据管理解决方案强制执行的参照完整性和关系头，则某些数据管理任务会更容易。 OODBMS模型中没有这些特征（至少到目前为止）。
博客上存在很多噪音，关系数据库已经过时，但RDBMS仍然是绝大多数数据管理任务的最佳通用解决方案。
答案 1 :(得分：21)
我看到的最大问题是缺乏标准化。在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。
OODBMS供应商：要改变这一点，您需要make it easy to leave you for your competitors。您可以挖掘OQL并实际实现它，或者在ODBC级别（如ODBC）或其他任何方面执行此操作。即使是标准转储格式（使用JSON？），以及用于导入/导出多个OODBMS的工具，也是一个很好的开始。
答案 2 :(得分：16)
数据通常寿命更长，比程序更重要。因此，即使您今天开始开发绿地，您也必须考虑整体情况。有更多工具，流程和经验丰富的人员使用RDBM系统。超越该计划，如何进行容量规划，数据挖掘，报告，ETL，与其他数据源的集成等。您的公司如何收购另一家公司，从而将所有关系数据带入您的计划。 RDBMS和相关工具是如此根深蒂固，经过验证和强大，我在使用其他任何东西时都没有任何战略意义。 在一些小的利基可能但不是一般。
答案 3 :(得分：6)
对象数据库对于表示几何的问题有很好的利基，例如： CAD系统，其中对象图确实非常深。在大多数关系系统中，JOIN性能在大约7个表中迅速降低，因此CAD中的深度自引用结构在对象数据库中表现更好。
但是，像金融数据这样的重要应用程序可以用于关系表示。关系模型具有坚实的数学基础，SQL是一种成功且流行的语言。银行，经纪公司和保险公司等金融机构几乎没有动力转向RDBMS。
答案 4 :(得分：5)
对于trival示例，OODB和RDB可能非常不同。特别是如果你正在处理足够少量的数据，你可以一次性将它全部读入内存并一次性写出来。但最终OODB需要以类似RDB的格式保存数据 - 它们并没有那么不同。
考虑可能在应用程序中使用的任意对象图。每个对象可以由几个其他对象引用。保存对象图形时，不希望每次引用对象时都重复保存对象。首先，如果您有任何类型的循环或自引用，则保存对象方法将进入无限循环。但在一般情况下，这是浪费空间。相反，任何重要的数据存储都需要为每个存储的对象（密钥，通常是RDBMS术语中的代理键）声明唯一标识符。引用它的每个其他对象保存对象类型和键，它不会重复保存整个对象。所以这里我们在非RDB对象存储库中重新创建了外键。
接下来，假设我们想要存储与另一个对象（B）相关的对象列表（A1，A2，A3 ......）。我们已经确定我们将存储密钥而不是两次保存对象。但是你把钥匙存放在物体B上的物体A1，A2，A3 ......上，还是把钥匙存放在A上的物体B上？如果你以第一种方式存储它们，并且你拥有所需的所有A，你可以快速获取相关的B。反之亦然的第二种方式。但无论哪种方式都是单向交易。如果要查询存储内容的反向，并将对象存储为XML或JSON，那么通过大多数无关信息进行大量低效解析以查找每个文件中的密钥。以每个字段分隔的格式（如表格中的列）存储它们不是更好吗？
在多对多关系中，或者您需要在两个方向上找到大量对象的情况下，此策略变得非常低效。唯一有效的解决方案是创建一个帮助对象来存储关系，每个关系都有一个文件，这样文件就包含A的密钥和B的密钥，这样就可以快速查找它们。我们刚刚重新设计了交叉引用表。
包含列，唯一标识符（键），交叉引用表的表...这些是以可以有效检索对象的方式存储对象的基本需求。嗯......听起来像是熟悉的吗？关系数据库提供了这种功能。此外，多家供应商已经竞争了数十年来提供最快的数据存储和检索，以及用于备份，复制，群集，查询等的最佳工具。这对于与之竞争的新技术来说是非常重要的。最后我说RDBMS基本上是解决有效对象存储问题的一个非常好的解决方案。
这就是Hibernate存在的原因 - 将面向对象的接口放在高效的RDBMS存储系统上。你看到其他类型的存储真正闪耀的地方是不同的问题领域：
OODB的表现不如RDB，因为它们并没有根本不同 RDB可以保留，因为以节省空间和节省时间的方式保存大型对象图形，并且容错并且具有一定的数据完整性保证是RDB设计要解决的问题。第一名。这就是为什么JPA和Hibernate也会保持这种原因 - 因为它们弥合了对象和关系数据模型之间的差距。对象模型，便于在内存中操作，以及持久性的关系。
答案 5 :(得分：3)
一句话互操作性（周五晚上的大词＆lt; G＆gt;）
大多数企业必须使用在RDBMS上运行的旧系统。如果他们要使用OODBMS，他们仍然需要访问RDBMS以获得某些功能。维护一种访问数据的方式比两种方法更容易。
当您在OODBMS世界中拥有像Oracle和SQL Server这样的大品牌以及在各种环境中经过验证的性能时，您会看到更多使用它们的项目。
答案 6 :(得分：0)
我认为这是
的情况如果没有破坏，请不要改变它。
关系数据库非常根深蒂固。
答案 7 :(得分：0)
主要问题是编制索引！
索引标量值真的很好……对它们进行排序。
对于具有许多属性，方法，零件，组件等的值……没有通用规则……。
因此OODBMS像恐龙一样消失了！
但是RDBMS供应商集成了一些工具以在数据库中拥有对象，例如XML（研究和开发有时会为真正使用的特殊对象找到索引方式，但这很难……），并且还支持对对象的存储。通常在Java（Oracle）或.net（SQL Server）中的任何类型的对象（没有索引的可能性……）。
答案 8 :(得分：-1)
为什么关系数据库比对象数据库更常见这个问题的最直接答案是，大多数问题都可以使用关系数据库解决。绝大多数人都有一套特定的工具，他们每天都使用这些工具来解决他们遇到的几乎所有问题。程序员也是如此。许多程序员只需要一个关系数据库，因此关系数据库市场可以为他们服务。
但是，如果您为 CAD/CAM/CAE 行业开发软件，或者如果您开发链接分析应用程序来支持调查，或者如果您构建一个复杂的数据融合系统，您的工具箱中可能有一个对象/图形数据库因为它们在这些领域的表现比关系数据库要好得多。
免责声明：我在 Objectivity, Inc. 工作，我们生产、营销和销售可大规模扩展的分布式对象/图形数据库。