对象数据库的优缺点是什么?

• 熟悉 数据库管理员了解关系概念;对象的,不太多。
• 表演
• 成熟 SQL是一种功能强大、开发时间较长的语言。
• 供应商支持。 与OODBMS相比,您可以选择更多的第一方(SQL Server)和第三方(管理接口、映射和其他类型的集成)工具。

开发商 ,而且,正如你所指出的,我会从ORM中抽出一个。但到目前为止,关系模型已被证明是更可行的选择。

Object Orientated vs Relational Databases .

我一直在用 db4o 这是一个OODB,它解决了列出的大多数缺点:

• 性能-这是一个高度主观,但你可以看看 PolePosition
• 供应商支持和成熟度-可以随时间变化
• 不能由不使用相同框架的程序使用-有OODB标准,您可以使用 different frameworks
• easier !

我感兴趣的专业人士有:

• 易用性—在域层、持久层(映射)以及最后的SQL数据库中定义构建逻辑肯定违反了DRY。使用OODB,您可以定义自己所属的域。

我同意——OODB还有很长的路要走,但他们正在前进。还有一些领域问题可以通过OODB更好地解决,

对象数据库的一个缺点是它在数据和代码之间创建了紧密耦合。对于某些应用程序,这可能没问题,但对于其他应用程序则不然。关系数据库给您带来的一个好处是可以在数据上放置许多视图。

Ted Neward 解释了这一点,以及更多关于OODBMS的内容,比这更好。

这与性能无关。也就是说,使用OODB,基本上所有应用程序的性能都会更好。但这也会让很多DBA失业/不得不学习新技术。更多的人将失业,无法纠正数据中的错误。这不太可能使OODBs受到老牌公司的欢迎。加文似乎完全不知道,一个更好的链接应该是 Kirk

欺骗:

• 无法由以下程序使用: 不要同时使用相同的框架 用于访问数据存储,使 它更难在全世界范围内使用

• 非SQL数据库

• 数据库之间不兼容 类型(无法交换到其他数据库 代码)

• 婊子。我猜是加了一个新的 对象的属性不完全相同 桌子

斯伦

您陈述的所有理由都是正确的,但我认为OODBMS的问题在于逻辑数据模型。对象模型(或者更确切地说是70年代的网络模型)没有关系模型那么简单,因此它是次等的。

jodonnel,我不知道对象数据库的使用如何将应用程序代码与数据结合起来。如果设计得当,您仍然可以使用存储库模式从OODB中抽象应用程序,并替换为ORM支持的SQL数据库。

对于OO应用程序,OO数据库将更自然地适合持久化对象。

可能正确的是,您将数据绑定到域模型,但这是关键!

使用以域为中心的视图以单一方式查看数据、业务规则和流程不是很好吗?

缺点是,我想只是普遍缺乏成熟度和接受度。。。