MongoDB是面向对象的吗？

Question

他们在MongoDB的网站上写到MonogDB是面向文档的数据库，那么如果MongoDB不是面向对象的数据库，那又是什么呢？文档和面向对象的数据库有什么区别？

Answer 1

这个回复可能有点晚了，只是觉得值得指出，ODB和MongoDB还是有很大区别的。

通常，ODB 的重点是任意复杂域模型中对象之间的透明引用（关系），而无需使用和管理诸如 DBRef 之类的代码。即使你有几千个类，你也不必担心管理任何键，它们是免费提供的，当你在运行时创建这 1000 个类的实例时，它们会自动在数据库中创建模式 .. 甚至对于诸如具有集合集合的自引用对象之类的东西。

此外，您的事务可以跨越这些引用，因此您不必使用完全嵌入的模型。

这些概念是在 JPA 等 ORM 解决方案中利用的概念，托管的持久对象生命周期是从 ODB 空间中获取的，但巨大的区别是 ODB 中根本没有映射，并且关系作为一部分存储因此，没有运行时 JOIN 来解决关系，所有关系都以与 b-tree 查找相同的速度解决。对于那些使用过 Hibernate 的人，想象一下 Hibernate 没有任何映射文件，并且速度快几个数量级，因为在后台没有运行时 JOIN。

此外，ODB 允许跨模型中的任何关系进行查询，因此您不会像在 MongoDB 中那样仅限于特定集合中的查询。当然也支持hash/b-tree/aggregate索引，所以使用时查询速度非常快。

您可以在类级别演化 ODB 中任何类的实例，并在运行时解析正确的类版本。与它在 MongoDB 中的工作方式完全不同，它维护代码来决定如何处理由于发展无模式数据库而产生的各种形式的 blob（或值对象）......或者编写代码来访问和更改每个值对象，因为您想更改架构。

就分区而言，我认为为可以跨任意对象通信的域模型决定分区模型要容易得多，然后是找出最重要的、最终的嵌入策略您的集合包含 MongoDB 中的文档。作为一个荒谬的示例，您有一个联系人、一个地址和一个 ShoppingCart，它们在 JSON 文档中相关，您决定按 Contact_id 对联系人进行分区。绝对没有什么可以阻止您将这 3 个类视为对象而不是 JSON 文档，并将它们存储在 Contact_id 上，就像使用 MongoDB 一样。但是，如果您有另一个对象 Account 并且由于对帐户进行了一些聚合计费操作，您想以非嵌入式方式管理这些对象，您可以在 ODB 中免费拥有它（无需为 DBRef 类型创建代码） ...您可以选择与联系人一起分区或选择将帐户存储在一个完全独立的物理节点中，但它会在运行时在应用程序空间中连接...就像魔术一样。

如果您想观看一个非常酷的视频，介绍如何使用 ODB 创建应用程序，其中显示分布、对象移动、容错、性能优化 .. 看这个（如果您想跳到很酷的部分，请跳转21 分钟后，您将避免构建应用程序，只需了解为任何现有应用程序添加分发和容错是多么容易）：

http://www.blip.tv/file/3285543

Answer 2

我认为面向文档和面向对象的数据库是完全不同的。相当详细的帖子在这里：

http://blog.10gen.com/post/437029788/json-db-vs-odbms

Answer 3

面向文档

• 文档（对象）很好地映射到 编程语言数据类型
• 嵌入式文档和数组减少 需要加入
• 动态类型（无模式）用于 简单的架构演变
• 没有连接和没有（多对象） 高性能交易和 易于扩展

(MongoDB Introduction)

据我了解，MongoDB 将每条记录都视为文档，无论它是 1 个字段还是 n 个字段。您甚至可以在文档中嵌入文档。您不必定义在其他关系数据库系统（MySQL、PorgeSQL 等）中受到非常严格控制的模式。我使用 MongoDB 有一段时间了，我真的很喜欢它的理念。

面向对象是一种数据库模型，其中信息以面向对象编程（维基百科）中使用的对象形式表示。

Answer 4

面向文档的数据库是与对象和关系数据库不同的概念。 文档数据库可能包含字段，也可能不包含字段，而关系数据库或对象数据库则期望缺失的字段用空条目填充。

想象一下将 XML 或 JSON 字符串存储在数据库表的单个字段中。这类似于文档数据库的工作方式。它只是允许将半结构化数据存储在数据库中，而无需大量空字段。