logo标签列表

面向对象数据库仍在使用吗？

databaseoopobject-oriented-database
17

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

10个回答
12

面向对象数据库从未走出过小众市场。它们适用于某些应用 - 当数据结构适合以对象图表示时 - 但在跨越鸿沟方面从未像关系型数据库那样具有令人信服的优势。 OO 数据库产品宣传的主要优势是与宿主语言的紧密集成 - 没有对象/关系阻抗不匹配。

然而，仍然有几家 OODBMS 供应商，例如 Gemstone、Versant 或 Cardinal，他们的产品表现得非常好。该技术对某些类型的数据结构很有用，并且可能比关系型数据库更有效率，但相对于现代 SQL 方言，它往往在针对特定问题的查询方面表现较弱。

正如 各种 其他人 所指出的，由于其对 Seaside 和 Maglev（一个将 Ruby 移植到 Gemstone VM 并在其上运行 Rails 的端口）的支持，Gemstone 正受到一些关注。我们可能会发现这会给来自 Gemstone 的好人带来一些新闻报道，以及对 OODBMS 范例更多的关注。

1
在像Gemstone这样的OODBMS中查询比SQL更适合于特定查询。 - Stephan Eggermont
6
事实上，数据库系统是其中一个非常难以进行根本性改变的领域。数十亿美元被花费在关系型数据库系统上，并且它们运作得相当良好。
但在现实生活中，这并不完全正确。我们在数据库方面遇到问题的一个主要原因（据称30%的所有数据库行都包含错误）是在SQL中使用了非常基础的类型和验证。此外，尽管它们被命名为关系型，但它们在处理关系方面非常糟糕。结果是非规范化的数据模型和由此产生的更新错误。
企业喜欢关系型数据库的原因是它们非常可预测。他们需要在其上花费大量资金，需要很多开发人员和维护人员来完成大部分例行工作。他们未能看到可以消除的重复量作为优势。例行工作使开发人员能够吸收困难工作的风险。转换到OODB将保留较不可预测的工作。
4
4
实际上，数据库系统是其中一个基本变化很难的领域。数十亿美元已经投入到关系型数据库系统中，并且它们运行得非常好。它们是经过验证的技术，它们也足够灵活，可以满足大多数需求（例如使用ORM）。实际上，对象数据库确实存在，甚至在学术界之外也是如此。但是不要指望在这个领域看到像SQL Server或Oracle那样大规模的东西。它们作为理论和小型应用特定数据库以及各种产品存在。基本上，我预测关系型数据库在未来会更加面向对象化，以更好地处理需求。
4

我最近开始使用 Gemstone。GLASS（Gemstone 在 Linux（或 OS-X）和 Seaside（Smalltalk Web 框架）上运行）可能是用于复杂应用的最佳 Web 开发环境。Smalltalk 正在经历复兴，被誉为“真正的 Ruby”。

与 RDBMS 相比，它支持模式更改和查询的功能要优秀得多。

一个重要的区别是这次它们是价格实惠的。

3
我需要关于快速对象的一些帮助。当我解析大约15GB的XML时，经常会出现虚拟内存不足的情况。我正在使用expat解析器。您有类似的经验吗？ - sameer karjatkar
我们实际上并不会自己解析XML，而是使用Versant的“ptxml”实用程序来导出/导入XML格式的FastObjects数据库，但仅限于此。 - Jay
3
因为他们的软件成本不够易于查明。
我查看了Objectivity、db4o和Versant，但它们的网站上都没有提供软件价格。
仅仅因为这个原因，我已经几乎失去了兴趣。
有人知道哪里可以比较所有这些不同OODB的定价和许可证吗？
4
+1 指同意。"Call us for a quote" 始终意味着“价格不菲”- 似乎没有好的、实惠的或非流行的开源软件、成熟的对象数据库。 - Michael Stum
客观性自此帖子以来走了很远的路，但仍然相当昂贵。 - St-Ste-Ste-Stephen
2

使用GemStone作为大型企业应用程序的数据存储方案非常好，也非常实用。我们已经使用了几年，它让我们能够在资源有限的情况下完成了很多工作。不幸的是，人们对于对象数据库存在很多误解，这使得它们在商业领域变得不太相关。希望未来像GLASS（GemStone、Linux和Seaside Smalltalk）这样的技术可以改变这种状况。

1

对象数据库是一个很酷的概念，但是实现中存在可扩展性和稳定性问题。现在，只要有正确的具体实现来解决这两个问题，情况可能会改变。

我的想法是，数据引擎（不一定是对象数据库）和关系型数据库可以真正并存，事实上，在中间层、嵌入式应用/系统中有一个很好的位置供数据引擎使用。此外，正确实现数据引擎将允许支持低级别的对象持久化和高级别的关系型数据库/SQL结构。这意味着您的应用程序可以选择使用对象来工作，使用数据引擎进行对象持久化，并通过关系型数据库接口将对象作为表格的行/列提供。

这是理想的设置。我们桥接了两种技术，并为开发人员提供了在其首选界面中编程的替代方案。有人可能会认为我们现在已经有了这个功能，例如 - SQL Server支持托管CLR对象，但当前的实现受到阻抗减速的影响。也就是说，在数据路径中存在大量的转换/翻译，因为对象!=二维数据，因此当处理对象的应用程序将它们保存到数据库时，解决方案必须将它们转换/翻译为表中的行数据。

但是，如果我们反过来看，即数据引擎操作对象，则不会出现阻抗不匹配。添加二维数据投影只是对象集合接口实现的一部分，因此当对象作为表格数据行公开时，实际上没有发生任何映射/转换。这是我的理论。

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

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

为了使其正常工作，数据引擎必须满足关系数据库管理系统所需的可扩展性和稳定性。这是一项非常艰巨的任务，但并非不可能完成。B-Tree Gold 4.0 SOP版本已经满足了这个要求，因此我们真正准备实施这种解决方案，而不会将其强加在我们的脖子下，因为SOP可以自由选择如何使用它。它可以用于许多方式，例如 - 作为中间层缓存站来补充关系数据库管理系统，在客户端嵌入式数据库等等...更不用说成为关系数据库管理系统服务器本身的低级数据引擎！
0

至少在我看来，它们几乎已经死亡了。但是，我主要从事商业软件开发工作。也许在学术领域还有人在使用。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接