23

我对编程很陌生（刚完成大学）。

在过去的 4 年中，我一直在思考面向对象的开发以及这种方法的众多优势。

我的问题是

在开发应用程序中使用纯面向对象的数据库不是更容易吗？

为什么面向对象数据库不像关系数据库那样分散？

从我的角度来看，使用 OO 数据库是有意义的，后者将避免在表上映射复杂对象所需的大量构造。

4

9 回答 9

14

过去曾在一家面向对象的数据库公司 ( www.objectstore.com ) 工作过 - 现在 - 我认为我对是什么让它们变得如此出色，以及是什么让它们变得不那么出色有一个公平的洞察力。

伟大的：

没有对象关系不匹配。如果您想将内存中的对象 x 存储到持久存储中，ObjectStore 可以通过近乎实时的保证来做到这一点。我们的产品已被许多公司用来满足对关系数据库或 ORM 引擎来说难以满足的苛刻时间要求。

没有对象关系不匹配——你在对象中发展，你在对象中思考，你在对象中存储。

不太好：

ORM：对象关系管理器几乎使对象数据库变得无关紧要

模式演变：更改一个类以添加一个字段，现在您必须变形整个数据库。多年来，ObjectStore 在这方面变得越来越聪明，但这仍然是许多 OODBMS 的痛点。

坏的：

工具支持——这使得 OODBMS 在大多数地方都无法启动。今天的每个人都可以使用 Crystal Reports 或 Access 或 Excel 并大量制作报告。使用 OODBMS，您必须通过程序员来构建此逻辑，并且我们都知道当您需要预算报告以考虑您在设计时没有想到的某些 xyz 参数时，这可能会发生多快。

工具是 OODBMS 在市场上失败的原因。不是技术优势或性能或语言支持（ObjectStore 支持 C++/Java/.Net 并且支持 COM 以支持任何 IDispatch 语言，如 VB、Perl 等）。

所以我在这里说了一些贬低的话，尤其是关于我真正喜欢的产品。但是 ObjectStore 在非常特定的任务上非常出色，但对于构​​建 web 应用程序来说却是一个糟糕的选择。虽然在某一时刻，它正在推动Amazon.com的库存管理后端。

于 2010-06-08T20:34:35.093 回答
10

正如您所说，您刚从大学毕业，并且刚刚被强烈灌输了 The One True (Object-Oriented) Way。另一方面，如果您学习过声明式编程、数据库设计和集合论，您会意识到关系模型是一种完全合适的方法，具有良好的理论基础，而 OO 是一种更实用的方法，主要是在工业中发明的而不是学术界。碰巧的是，关于数据库问题的最有趣的研究和开发是由具有更多数学背景的人完成的，对他们来说，关系模型是处理数据的更自然的方式。因此，RDBMS 往往比面向对象的同类产品更稳定、更可扩展和更受信任。面向对象的数据库，很像 XML，

于 2010-06-08T20:38:41.610 回答
6

如果您已经拥有一个数 GB 大小的关系数据库，并且已经存储了 20 年的数据并且拥有数百或数千个表，那么使用这种方法没有任何优势。这是许多业务应用程序的真实世界。数据库不仅仅用于特定应用程序的对象映射。在您编写的应用程序消失后，数据库仍然存在很长时间。咬紧牙关学习关系数据库，因为它们在未来 100 年内不会消失。

于 2010-06-08T19:39:16.267 回答
2

十年前，我研究了面向对象的数据库设计（用于个人项目），发现它们不太擅长轻松或快速地进行某些类型的搜索（比如“找到所有姓氏以'S'开头的人），虽然当然有很多关系查询在面向对象的数据库中是不需要的。此外，当时面向对象的数据库还没有真正准备好进行大规模部署（这当然不是我关心的问题）。我相信较新的已经解决了这个问题，但是仍然有很多 intertia 和良好的 ORM 使得使用关系数据库相对容易。

但是，有一个远离关系数据库的运动，请参阅NoSQL 运动。我相信谷歌不使用关系数据库（但也不是面向对象的，而是专有的和分布式的）。

于 2010-06-08T19:57:04.490 回答
2

很抱歉无法将其作为评论添加到它真正应该出现的地方。

但以下内容构成对我的人身攻击，我援引我的回应权。

虽然我在实践上同意你，但在精神上我不同意你，我认为你是被洗脑的人，相信基于集合是唯一的方法（也许我在你嘴里说的话）。

FWIW，我肯定没有被“洗脑”成你可能称之为“关系宗教信仰”的东西。洗脑是指某个导师说了些什么，而学生盲目而无脑地接受这是唯一的真理，没有任何形式的批判性思维。事实上，我什至从未学过关系模型。事实上，我必须自己去发现这一切。我对伊达在观点更新问题上的观点提出了严厉的批评，这是有据可查的。（更正：“是”一个记录事实。该页面似乎已从发布它的站点中删除。可能与 Date 确实放弃了我批评的视图更新位置这一事实有关。）

所以我认为我有充分的理由说，我曾经让自己被洗脑的任何说法都是彻头彻尾的荒谬。你可以随心所欲，但如果你公开发表任何无端的、毫无根据的个人意见，我希望你也够成年人，看到他们被事实反驳并承认。

分层和网络模型已被 RM 取代的原因已在整个图书馆充分记录了有关该主题的书籍。我邀请你仔细检查那些。

至于“key-value正在接管市场”：你完全可以自由地接受“市场最普遍的意见”（即：平庸的大多数懒得自己思考的傻瓜相当快乐让他们自己（和他们的意见）被这个世界的埃里森、盖茨和乔布斯领导）作为衡量什么是有价值的，什么是不有价值的主要标准。我个人觉得这样做很愚蠢，但这只是我个人的看法。我在这里复制粘贴一些几乎在其职业生涯的每一天都面临 EAV 和 Key-value 的恐惧的人的一些观察：

我为许多但不是全部逻辑表使用以下“EAV 模型”（至少是我理解的“EAV 模型”）的应用程序：

R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}

其中可能会看到以下值：

R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
     {'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
     {'STATE_CODES', 'ALASKA',  'AK'} ...}

基本上，“EAV relvars”是通过在 R1 和 R2 中插入/更新/删除来创建/更改/删除的（与 DDL 相比）。这是我们整个模型的精简版：在 R1 和 R2 中有额外的列来指定 eav-primary-keys、eav-foreign-keys、业务规则等......所有这些都由嵌入在“one”中的程序代码强制执行模型的真正前端”。

今天早上，当系统 A 认为 CODE_XYZ 将在 ATTRIBUTE2 中时，我参与了 20 多个工时的考验，但系统 B 实际上将其定义为 ATTRIBUTE3 ......我不得不笑我听了一半的事实到谈话中去，半读这个小组关于 EAV 的论述。

上个月，我进行了一次紧急更新（16 个工时加上应用程序的“坏标记”），将 430 个用户输入的数据点的 ATTRIBUTE16 从“2010 年 5 月”更改为“2010 年 5 月”。

我们大约 5-10% 的代码发布伴随着“周一早上运行时错误清理”，因为 EAV_RELVARs 在生产中没有像在测试/开发中那样被编码到 R1 或 R2 中（应用程序代码和 DDL 都使用严格的版本控制软件控制......我们的 EAV 模型不受官僚主义的束缚，因为它“允许”开发人员在开发、测试和生产中自主设置他们的 EAV。）。

去年，我花了整整 3 周的时间专门调整复制软件来解决 R3 上缺少主键的问题。

我曾经不得不为无法在 EAV_RELVAR_NAME_x 的 ATTRIBUTE4 上放置索引而道歉，因为它破坏了使用 EAV_RELVAR_NAME_z 的不同程序的性能。

两年前，在花费数百小时不断调整需要加入 R3 的复杂查询之后，我终于花了 3 个月的时间将 R3 分成数百个物理分区（每个 EAV_RELVAR_NAME 一个），以便为 DBMS 优化器提供统计信息需要看到有 50 个“STATE_CODES”和 200,000 个“LOCATION_CODES”。我很庆幸这个巧妙的解决方案，虽然讽刺的是每个人都错过了当我指出，随着这个变化，将有一个新的策略，即添加一个新的 EAV_RELVAR_NAME 将需要运行一个脚本，该脚本将一个关联的分区添加到 R3（是的，与 DDL）。

我的客户想要一个新的前端来为他们的 EAV_RELVAR_NAME 之一加载数据到 R3（同时强制执行所有适当的约束和安全性），他们想知道为什么需要 4 个月的时间来构建。

我经常指出，我可以用一种在各方面都更出色的方式重写整个 EAV 系统，使用针对数据字典的动态 DDL 而不是针对 R1 和 R2 的 DML，但我总是被告知我们“致力于“对于这种方法（构建它需要 7 位数的前期支出，我们必须重写 98% 的代码库才能切换到独立表），并且目的并不能证明方法的合理性.

如果你真的相信这样的场景是对 RM 的改进，那么一定要继续。当你最终把头撞到墙上时，别怪我有多痛。

于 2010-06-09T09:10:47.767 回答
1

这没有充分的理由，尤其是随着 ORM（Active Record）使用的兴起和映射的痛苦。面向对象的数据库在许多方面都更快更好。不受欢迎的原因是需要。到目前为止，RDBMS 一直做得很好，在大型企业中，最大的痛苦就是所谓的“迁移”。与大多数技术一样，用户的需求是首要目标，而面向对象通常不是卖点。速度也许可以，但昂贵的硬件和经过验证的 RDBMS 调优也可以实现性能。

同样，在这方面熟练的人也必须再次接受培训（这要花很多钱）。更不用说那些学习邪恶 PL/SQL 的昂贵顾问了……

我会说，做一个先行者。就像圣雄甘地所说，成为你想看到的改变。有趣的是，你只是让我想在谷歌上搜索一个开源的 OO-DB。

于 2010-06-08T19:46:18.870 回答
1

面向对象数据库的采用如此缓慢的一个原因是，可扩展的开源替代方案并不多。对于 RDBMS，例如 MySQL（Oracle 现在拥有）、PostgreSQL 等等。

另一个问题是，至少对于 Java，RDBMS 访问 JDBC 的标准 API 和 ORM 部分的 JPA 背后有更大的公司，而且知名度更高。面向对象数据库访问的 JDO 是一种标准，但没有那么流行。

在大多数情况下，面向对象的数据库比 RDBMS 具有更强大的 API 或语言锁定，这也是拥有多个平台和语言投资的大公司继续使用 RDBMS 的另一个原因。

对我个人而言，流行的开源 OO 数据库将是投入更多时间来尝试它们的一个理由。

于 2010-06-08T20:35:52.490 回答
1

数据库不仅仅是存储和检索对象，否则 OODB 和文档 DB 将接管世界。其他使用上下文/方面包括：

  • 聚合数据并进行复杂的批量数据处理/操作。RDBMS 非常擅长这一点。
  • 其他重要方面是并发/隔离（即事务）。RDBMS 在这方面非常成熟。
  • 另一方面是索引以确保快速查询。
  • 另一个方面，比如上面提到的“Chris Kaminski”，是能够在保留数据的同时随着时间的推移演变你的模式。

最后，还有一点行业惯性，主要供应商不愿意把钱押在客户还没有准备好支付的东西上，而客户则在观望，直到主要供应商加入游戏。

于 2010-06-08T20:56:51.997 回答
0

另一个问题是语言支持。那些不是面向对象的语言呢？一个好的数据库需要每个人都可以访问，不管是什么语言。这就是为什么许多特定语言的数据库失败的原因，因为他们的市场只是该语言的人。

还有迁移因素。MySQL 最大的用户是长期用户。迁移到具有与现有大型数据库完全不同的基本设计的全新数据库系统将非常昂贵并且几乎没有回报。

于 2010-06-08T19:52:16.340 回答