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

【问题标题】：How do document databases deal with changing relationships between objects (or do they at all)?文档数据库如何处理对象之间不断变化的关系（或者根本不处理）？
【发布时间】：2011-09-03 00:50:53
【问题描述】：

假设在项目开始时，我想存储公司的集合，并在每个公司中存储员工的集合。

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

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

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

如何管理文档数据库中的这种变化？

文档数据库的简单性是否会成为您最大的敌人，因为它会创建不易修改的脆弱数据结构？

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

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

在那种情况下，我是否还在按我应该的方式使用文档数据库？

是不是越来越像关系型数据库了？

【问题讨论】：

标签： mongodb relational-database document-database

【解决方案1】：

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

How would I model data that is heirarchal and relational in a document-oriented database system like RavenDB?

【讨论】：

【解决方案2】：

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

说了这么多，使用像 MongoDB 这样的系统的关键是对数据进行建模以适应 MongoDB。如果您使用 MySQL，则上述内容完全有意义……如果您像关系数据库一样构建数据，那么使用 Mongo 绝对会遇到麻烦。

如果您有Employees 可以在一个或多个Companies 工作，我会将其结构为：

// 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.companies 上添加一个索引，这样可以非常快速地找到为给定公司工作的所有员工......无论他们为多少家公司工作。为每位员工维护一份简短的公司名单比为一家公司维护大量员工名单要容易得多。要获取公司及其所有员工的所有数据将是两个（快速）查询。

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

简单性可能会咬你，但它非常很容易在以后更新和更改。您可以通过 Javascript 编写更改脚本并通过 Mongo shell 运行它们。

【讨论】：