Mongodb 文档数据库如何处理对象之间不断变化的关系（或者根本不处理）？

比如说，在项目开始时，我想存储一个公司集合，在每个公司中存储一个员工集合

由于我使用的是文档数据库（如MongoDB），因此我的结构可能如下所示：

+ Customers[]
   +--Customer
      +--Employees[]
         +--Employee
         +--Employee
   +--Customer
      +--Employees[]
         +--Employee

如果后来有一个新的要求是让一些员工在多家公司工作，会发生什么

如何管理文档数据库中的此类更改

文档数据库的简单性难道不是你最大的敌人吗？因为它创建了不易修改的脆弱数据结构

在上面的示例中，我必须运行修改脚本来创建一个新的“Employees”集合，并将每个员工移动到该集合中，同时维护某种关系密钥（例如，每个员工上的CompanyID）

如果我做得足够彻底，我最终会有很多集合，层次结构很少，文档通过键连接

在这种情况下，我是否仍在使用文档数据库

---

它不是越来越像一个关系数据库了吗？

特别是说到MongoDB……因为数据库没有像关系数据库那样强制执行任何关系，所以您需要维护这样的任何类型的数据完整性。它在很多情况下都非常有用，但最终会编写更多的应用程序代码来处理这类事情

话虽如此，使用像MongoDB这样的系统的关键是为数据建模以适应MongoDB。如果您使用的是MySQL，那么上面的内容就完全有意义了……如果您将数据结构化为关系数据库，那么使用Mongo绝对会遇到麻烦

如果您有

员工

，他们可以在一家或多家

公司

工作，我会将其组织为：

// company records
{ _id: 12345, name : 'Apple' }
{ _id: 55555, name : 'Pixar' }
{ _id: 67890, name : 'Microsoft' }

// employees
{ _id : ObjectId('abc123'), name : "Steve Jobs", companies : [ 12345, 55555 ] }
{ _id : ObjectId('abc456'), name : "Steve Ballmer", companies : [ 67890 ] }

您需要在

employees.companys

上添加一个索引，这将使获取为给定公司工作的所有员工的速度非常快……无论他们为多少家公司工作。为每个员工维护一份简短的公司列表要比为一家公司维护一份庞大的员工列表容易得多。要获取一家公司及其所有员工的所有数据，需要两个（快速）查询

文档的简单性不是很重要吗 数据库成为你的敌人， 因为它会创建脆弱的数据 不容易被破坏的结构 修改

---

这种简单性可能会让你头疼，但很容易在以后进行更新和更改。您可以通过Javascript编写更改脚本，并通过Mongo shell运行这些更改。

我最近对这个问题的回答在RavenDb上下文中介绍了这一点：