Question

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

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

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

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

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

文档数据库的简单性是不是会成为你的敌人，因为它会创建脆弱的数据结构，而这些数据结构无法轻易修改？

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

如果我彻底完成了上述工作，我最终会得到许多集合，而且层次结构很少，文档通过密钥加入。

在这种情况下，我还在使用文档数据库吗？

是不是变得更像关系数据库？

Answer 1

特别谈到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运行它们。

Answer 2

我最近对此问题的回答涵盖了RavenDb上下文中的内容：

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

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

2 个答案: