2

比如说，在项目开始时，我想存储一组公司，并在每个公司内存储一组员工。

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

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

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

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

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

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

如果我足够彻底地完成上述操作，我最终会得到很多集合，并且层次结构很少，并且文档通过键连接。

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

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

4

2 回答 2

3

具体来说说 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 运行它们。

于 2011-05-27T00:45:40.367 回答
1

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

在像 RavenDB 这样的面向文档的数据库系统中，我将如何对分层和关系数据进行建模？

于 2011-06-09T09:11:03.163 回答