为什么OODBMS不像RDBMS那样广泛？

为什么关系数据库比面向对象的数据库更常见？

如果面向对象编程范例如此广泛,我们不应该看到很多OODBMS吗？它们不会比RDBMS + OR/M表现更好吗？

RDBMS保持流行的一个原因是它已经成熟的技术,很好理解并且具有多个供应商支持的标准语言(SQL).它还有一些很好的接口,如ODBC和JDBC,可以很好地连接不同的语言.稳定的API是保持技术占主导地位的重要因素.

相比之下,没有明确的OODBMS模型,也没有标准语言,也没有标准API.拥有领先的供应商实施甚至没有事实上的标准.

OODBMS概念可能比RDBMS + ORM表现更好.这完全取决于实施.但是,OODBMS也无法解决RDBMS擅长解决的同一组问题.如果您具有数据管理解决方案强制执行的参照完整性和关系头,则某些数据管理任务会更容易.OODBMS模型中没有这些特征(至少到目前为止).

博客上存在很多噪音,关系数据库已经过时,但RDBMS仍然是绝大多数数据管理任务的最佳通用解决方案.

我看到的最大问题是缺乏标准化.在RDBMS世界中,如果您了解SQL,则可以使用任何随机数据库.它们基本上都是实现它,只有很小的变化.我不知道单个现有的RDBMS不能执行SQL:您几乎可以互换地使用"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供应商:要改变这一点,您需要让您轻松离开竞争对手.您可以挖掘OQL并实际实现它,或者在ODBC级别(如ODBC)或其他任何方面执行此操作.即使是标准转储格式(使用JSON？),以及用于导入/导出多个OODBMS的工具,也是一个很好的开始.

数据通常寿命更长,比程序更重要.因此,即使您今天开始开发绿地,您也必须考虑整体情况.有更多工具,流程和经验丰富的人员使用RDBM系统.超越该计划,如何进行容量规划,数据挖掘,报告,ETL,与其他数据源的集成等.您的公司如何收购另一家公司,从而将所有关系数据带入您的计划中.RDBMS和相关工具是如此根深蒂固,经过验证和强大,我在使用其他任何东西时都没有任何战略意义.在一些小的利基可能但不是一般.

对象数据库对于诸如表示几何的问题(例如CAD系统)具有非常好的利基,其中对象图确实非常深.在大多数关系系统中,JOIN性能在大约7个表中迅速降低,因此CAD中的深度自引用结构在对象数据库中表现更好.

但是,像金融数据这样的重要应用程序可以用于关系表示.关系模型具有坚实的数学基础,SQL是一种成功且流行的语言.银行,经纪公司和保险公司等金融机构几乎没有动力转向RDBMS.