有很多关于对象关系映射器以及如何最好地避免阻抗不匹配的信息，如果要使用对象数据库，所有这些似乎都没有实际意义。我的问题是为什么不更频繁地使用它？是因为性能原因还是因为对象数据库导致您的数据成为应用程序的专有，还是由于其他原因？
Kevin Pang
问问题
4686 次
7 回答
12
- 熟悉。数据库管理员知道关系概念；反对的，不是那么多。
- 表现。关系数据库已被证明可以更好地扩展。
- 到期。SQL 是一种功能强大、开发已久的语言。
- 供应商支持。与 OODBMS 相比，您可以在更多的第一方（SQL 服务器）和第三方（管理接口、映射和其他类型的集成）工具之间进行选择。
自然，面向对象的模型对开发人员来说更熟悉，而且，正如您所指出的，它会省去 ORM 的一个。但到目前为止，关系模型已被证明是更可行的选择。
另请参阅最近的问题，面向对象与关系数据库。
于 2008-09-14T18:11:49.633 回答
10
我一直在使用db4o，它是一个 OODB，它解决了列出的大部分缺点：
- 熟悉度 - 程序员比 SQL 更了解他们的语言（请参阅本机查询）
- 性能 - 这个是非常主观的，但你可以看看PolePosition
- 供应商支持和成熟度 - 会随着时间而改变
- 不能被不使用相同框架的程序使用 - 有 OODB 标准，您可以使用不同的框架
- 版本控制可能有点麻烦 - 版本控制实际上更容易！
我感兴趣的优点是：
- 本机查询 - Db4o 允许您使用静态类型语言编写查询，因此您不必担心错误输入字符串并在运行时发现数据丢失，
- 易用性——在领域层、持久层（映射）和最后的 SQL 数据库中定义业务逻辑肯定违反了 DRY。使用 OODB，您可以定义它所属的域。
我同意 - OODB 有很长的路要走，但他们正在前进。还有一些领域问题可以通过 OODB 更好地解决，
于 2008-10-05T07:01:38.350 回答
2
对对象数据库的一个反对意见是它在数据和代码之间创建了紧密耦合。对于某些应用程序，这可能没问题，但对于其他应用程序则不然。关系数据库为您提供的一件好事是可以在数据上放置许多视图。
Ted Neward解释了这一点以及更多关于 OODBMS 的内容，比这更好。
于 2008-09-14T18:13:44.573 回答
2
它与性能无关。也就是说，基本上所有应用程序在使用 OODB 时都会表现得更好。但这也会使许多 DBA 失业/不得不学习新技术。更多的人会因为纠正数据中的错误而失业。这不太可能使 OODB 受到成熟公司的欢迎。加文似乎完全一无所知，更好的链接是柯克
于 2009-09-25T20:58:32.513 回答
1
缺点：
不能由不使用相同框架来访问数据存储的程序使用，从而使其更难以在整个企业中使用。
可用于非基于 SQL 的数据库的在线资源较少
跨数据库类型不兼容（不能在不更改所有代码的情况下切换到不同的数据库提供程序）
版本控制可能有点麻烦。我猜想向对象添加新属性并不像向表中添加新列那么容易。
于 2008-09-14T18:13:09.053 回答
0
索伦
您所说的所有原因都是有效的，但我认为 OODBMS 的问题在于逻辑数据模型。对象模型（或者更确切地说是 70 年代的网络模型）不像关系模型那么简单，因此是次要的。
于 2008-10-04T09:34:48.433 回答
0
jodonnel，我不明白对象数据库的使用如何将应用程序代码与数据结合起来。如果设计得当，您仍然可以通过使用存储库模式从 OODB 中抽象出您的应用程序，并替换为支持 ORM 的 SQL 数据库。
对于 OO 应用程序，OO 数据库将更自然地适合持久化对象。
可能正确的是您将数据与域模型联系起来，但这就是症结所在！
使用以域为中心的视图以单一方式查看数据、业务规则和流程不是很好吗？
因此，一个很大的优点是 OODB 与大多数现代企业级面向对象软件应用程序的设计方式相匹配，不需要额外的努力来使用不同的（关系）设计来设计数据层。构建和维护成本更低，在许多情况下通常性能更高。
缺点，我认为只是普遍缺乏成熟和采用...
于 2008-10-06T04:21:38.173 回答