面向对象的数据库是否仍在使用？

Question

很久以前，我听说过Object数据库。酷的概念和所有。现在，随着各地ORM的发生，还有人还在使用任何面向对象的数据库系统吗？它们相关吗？它们实用吗？

Answer 1

OO数据库从未脱离利基市场。它们适用于某些应用程序 - 数据结构有助于用对象图表示 - 但从来没有比RDBMS更具吸引力的优势来跨越鸿沟。 OODBMS产品的主要优势在于与主机语言的紧密集成 - 没有对象/关系阻抗不匹配。

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

正如various others所指出的那样，Gemstone因为支持Seaside和Maglev（Ruby的端口而受到一些关注运行Rails的Gemstone VM）。我们可能会发现这可以让Gemstone的好朋友有点压力，并且更加关注OODBMS范例。

Answer 2

  

实际上，数据库系统是其中之一   基本面变化的领域   真的很难。数十亿美元   花在关系数据库系统上   而且他们工作得很好。

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

企业喜欢关系数据库的原因是因为它们非常容易预测。他们不得不在他们身上花费很多钱，他们需要大量的开发人员和维护工作来完成日常工作。他们没有看到可以作为优势消除的重复数量。日常工作使开发人员能够承担困难工作的风险。切换到OODB将保持较不可预测的工作。

Answer 3

查看db4o。

Answer 4

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

Answer 5

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

对架构更改和查询的支持远远优于RDBMS。

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

Answer 6

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

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

Answer 7

因为他们的软件成本不容易找到。

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

由于这个原因，我几乎已经失去了兴趣。

有没有人知道所有这些不同的oodbs有定价和许可证比较的地方？

Answer 8

将GemStone用于大型企业应用程序。这很棒，非常实用。我们已经使用它好几年了，在那段时间里它使我们能够用很少的资源做很多事情。遗憾的是，对于对象数据库存在许多误解，我认为这使得它们在商业世界中的相关性降低。希望GLASS（GemStone，Linux和Seaside Smalltalk）之类的东西能够改变未来的发展方向。

Answer 9

目标数据库是一个很酷的概念。但是，实现会受到可伸缩性和稳定性问题的影响。现在有了解决这两种野兽的正确化身，方程式可能会改变。

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

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

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

因此，该领域的下一波技术可能是一个数据引擎，它将允许对象作为低级接口和RDBMS接口。这项技术现已上市！

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

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

Answer 10

至少从我的观点来看，他们已经死了。但话又说回来，我主要在商业软件方面工作。也许在学术领域，他们仍然在某个地方使用。