关于对象关系映射器的信息很多，如何最好地避免阻抗不匹配，如果要使用对象数据库，所有这些似乎都是有争议的。我的问题是为什么不更频繁地使用它？是由于性能原因还是由于对象数据库导致数据成为应用程序专有的，还是由于其他原因？

解决方案

回答

• 熟悉度。数据库管理员了解关系概念。对象对象，没有那么多。
• 表现。关系数据库已被证明可以更好地扩展。
• 到期。 SQL是一种功能强大且经过长期发展的语言。
• 供应商支持。与OODBMS相比，我们可以选择更多的第一方(SQL服务器)和第三方(管理界面，映射以及其他类型的集成)工具。

自然，开发人员对面向对象的模型更为熟悉，并且，正如我们所指出的那样，它将避免使用ORM之一。但是到目前为止，关系模型已被证明是更可行的选择。

另请参见最近的问题，面向对象与关系数据库。

回答

缺点：

• 那些不使用相同框架访问数据存储的程序也无法使用，这使得在整个企业范围内使用变得更加困难。
• 非基于SQL的数据库可在线使用的资源更少
• 跨数据库类型不兼容(在不更改所有代码的情况下无法交换到其他数据库提供程序)
• 版本控制可能有点麻烦。我猜想向对象添加新属性并不像向表中添加新列那样容易。

回答

对对象数据库的一个反对意见是，它在数据和代码之间建立了紧密的联系。对于某些应用程序，这可能是好的，但对于其他应用程序则不是。关系数据库为我们提供的一个好处是可以在数据上放置许多视图。

Ted Neward对此进行了解释，并且有关OODBMS的更多内容要比这更好。

回答

S？ren

我们陈述的所有原因都是有效的，但是我看到OODBMS的问题是逻辑数据模型。对象模型(或者更确切地说是70年代的网络模型)不像关系模型那样简单，因此是次等的。

回答

我一直在使用db4o，它是一个OODB，它解决了列出的大多数缺点：

• 熟悉-程序员比SQL更了解他们的语言(请参阅本机查询)
• 性能-这是非常主观的，但是我们可以看一下PolePosition
• 供应商的支持和成熟度-会随着时间的推移而变化
• 不能同时使用同一框架的程序不能使用-有OODB标准，我们可以使用不同的框架
• 版本控制可能有点麻烦-版本控制实际上更容易！

我感兴趣的专业人士是：

• 本机查询-通过Db4o，我们可以使用静态类型的语言编写查询，因此我们不必担心会混淆字符串并在运行时查找丢失的数据，
• 易于使用-在域层，持久层(映射)以及最后SQL数据库中定义业务逻辑肯定违反了DRY。使用OODB，我们可以定义它所属的域。

我同意OODB还有很长的路要走，但是他们正在走。 OODB可以更好地解决领域问题，

回答

jodonnel，我看不到对象数据库的使用如何将应用程序代码耦合到数据。我们仍然可以通过使用存储库模式从OODB中提取应用程序，如果设计正确，则可以替换为ORM支持的SQL数据库。

对于OO应用程序，OO数据库将为持久化对象提供更自然的契合度。

我们可能将数据绑定到域模型可能是正确的，但这才是关键！

使用以域为中心的视图同时查看数据，业务规则和流程的单一方法不是很好吗？

因此，一个大优点是OODB与大多数现代的企业级面向对象的软件应用程序的设计方式匹配，因此无需花费额外的精力来使用不同的(关系)设计来设计数据层。构建和维护成本更低，并且在许多情况下，它们通常具有更高的性能。

缺点，我认为普遍缺乏成熟度和采用性。

回答

它与性能无关。也就是说，基本上所有应用程序都可以通过OODB更好地运行。但这也将使许多DBA失去工作/必须学习新技术。甚至会有更多的人无法纠正数据中的错误。这不太可能使OODB在成熟的公司中流行。加文(Gavin)似乎一无所知，一个更好的联系是柯克(Kirk)