16

很久以前，我听说过对象数据库。很酷的概念等等。现在，随着 ORM 事件无处不在，还有人使用任何面向对象的数据库系统吗？它们是否相关？它们实用吗？

4

10 回答 10

12

OO 数据库从未脱离利基市场。它们适用于某些应用程序——在这些应用程序中，数据结构适合用对象图表示——但从未拥有超过 RDBMS 以跨越鸿沟的引人注目的优势。OODBMS 产品的主要优势是与宿主语言的紧密集成——没有对象/关系阻抗不匹配。

但是，仍然有一些 OODBMS 供应商，例如Gemstone、Versant或Cardinal，他们的产品做得很好。该技术对某些类型的数据结构很有用，并且比 RDBMS 更有效，但与现代 SQL 方言相比，对于即席查询往往较弱。

正如其他许多 人所指出的那样，Gemstone 由于支持Seaside和Maglev（一个Ruby端口到 Gemstone VM 并在其上运行Rails ）而受到关注。我们可能会发现这让 Gemstone 的好人得到了一些关注，并因此对 OODBMS 范式有了更多的关注。

于 2008-12-09T16:55:00.653 回答
6

事实上，数据库系统是真正难以进行根本性改变的领域之一。数十亿美元用于关系数据库系统，并且运行良好。

在现实生活中，这根本不是真的。我们的数据库问题的一个主要原因（我看到所有数据库行中有 30% 包含错误）是在 SQL 中使用非常原始的类型和验证。此外，即使它们被命名为关系，它们在处理关系方面也很糟糕。结果是非规范化的数据模型和导致的更新错误。

企业喜欢关系数据库的原因是它们非常可预测。他们必须在他们身上花很多钱，他们需要很多开发人员和维护人员来做大部分日常工作。他们没有看到可以消除的重复数量是一种优势。例行的工作让开发人员承担了艰巨工作的风险。切换到 OODB 将保留不太可预测的工作。

于 2008-12-11T12:30:08.910 回答
4

查看db4o。

于 2008-12-09T16:09:46.207 回答
4

事实上，数据库系统是真正难以进行根本性改变的领域之一。数十亿美元用于关系数据库系统，并且运行良好。它们是经过验证的技术，并且足够灵活，可以满足大多数需求（例如，如您所说，使用 ORM）。对象数据库确实存在，甚至在学术界之外。但是不要指望很快就会在该领域看到像 SQL Server 或 Oracle 这样大的东西。它们确实作为一种理论存在，也作为小型的、特定于应用程序的数据库和各种产品存在。基本上，我预测关系数据库将来会变得更加面向对象，以更好地处理需求。

于 2008-12-09T16:10:10.587 回答
4

我最近开始使用宝石。GLASS（带有 Seaside（smalltalk web 框架）的 Linux（或 OS-X）上的 Gemstone）可能是复杂应用程序的最佳 web 开发环境。Smalltalk 正在复兴，成为“真正的红宝石”。

对模式更改和查询的支持远远优于 RDBMS。

一个重要的区别是，这次它们是负担得起的。

于 2008-12-09T17:58:41.260 回答
3

我们在我从事的产品中使用Versant 对象数据库。（以前的 FastObjects，以前的 Poet 数据库）。它是一个对象数据库，我们发现它在我们产品的某些方面工作得比关系模型好得多，主要是存储配置对象，与 Java 代码交互。

另请参阅这个先前提出的问题：https ://stackoverflow.com/questions/52144/object-oriented-database-experiences

于 2008-12-09T16:04:54.420 回答
3

因为他们的软件成本不容易查明。

我查看了Objectivity、db4o、versant，并且没有一个在他们的网站上预先列出软件的价格。

正因为如此，我已经几乎失去了兴趣。

有谁知道在哪里有所有这些不同 oodb 的定价和许可证比较？

于 2009-09-03T07:01:21.647 回答
2

将 GemStone 用于大型业务应用程序。这很棒而且非常实用。我们已经使用它几年了，在那段时间里，它使我们能够用很少的资源做很多事情。不幸的是，关于对象数据库存在许多误解，我认为这使得它们在商业世界中的相关性降低。希望像 GLASS（GemStone、Linux 和 Seaside Smalltalk）这样的东西会在未来改变这种情况。

于 2008-12-09T22:39:27.137 回答
1

到目前为止，对象数据库是一个很酷的概念。但是，实现存在可扩展性和稳定性问题。现在有了解决这两个野兽的正确化身，等式可能会改变。

我的想法是，数据引擎（不一定是对象数据库）和 RDBMS 可以真正并存，事实上，数据引擎在中间层、嵌入式应用程序/系统中是一个很好的地方，......还有，数据引擎的正确实现将允许在低级别和更高级别支持对象持久性，RDBMS/SQL 构造。这意味着您的应用程序可以选择使用对象，将数据引擎用于对象持久性，并通过 RDBMS 接口将对象作为表的行/列提供。

这是理想的设置。我们将这两种技术连接起来，并为开发人员提供在他们喜欢的界面中编程的替代方案。有人可能会争辩说我们现在有了这个，例如 - SQL Server 支持托管 CLR 对象，但是当前的实现受到阻抗减慢的影响。即 - 在数据路径中有很多转换/翻译为对象！= 二维数据，因此当您处理对象的应用程序将它们保存到数据库时，解决方案必须将它们转换/翻译为表中的行数据。

但是如果我们扭转这种情况，即数据引擎在对象上运行，那么就不会有阻抗不匹配。添加二维数据投影只不过是对象集合的接口实现，因此当对象作为表的数据行公开时，实际上并没有发生映射/转换。这是我的理论。

因此，该领域的下一波技术可能是数据引擎，它将允许对象作为低级接口和位于其之上的 RDBMS 接口。而且这项技术现在可用！

B-Tree Gold 4.0 Scalable Object Persistence 以此为主要设计目标。它实现了以下特性，因此非常适合作为下一个 RDBMS 的首选数据引擎，后者基本上是它之上的一层。它的两个主要关键点是： 可扩展性：在配备普通/普通笔记本电脑的 17 小时内插入 1 亿次。稳定性：工业强度的事务，将确保数据库不会损坏并且可以回滚到先前提交的状态。

为此，数据引擎必须满足 RDBMS 服务器所需的可扩展性和稳定性。一项非常艰巨的任务，但并非不可能。B-Tree Gold 4.0 版 SOP 已经满足了这个要求，因此，我们真的准备好实施这种解决方案，而不是把它放在我们的脖子上，因为 SOP 让您可以自由选择如何使用它。它可以用在很多方面，例如 - 作为中间层缓存站的补充 RDBMS 服务器，在客户端嵌入 DB 等等......更不用说作为 RDBMS 服务器本身的低级数据引擎！

于 2010-07-16T07:24:53.777 回答
0

至少从我的角度来看，他们几乎已经死了。但话又说回来，我主要从事商业软件工作。也许在学术领域，它们仍在某处使用。

于 2008-12-09T16:03:04.253 回答