NoSQL反模式_|*|#8211;_文档数据库篇_nosql数据库存储模式

首先,让我们先来了解一下什么是"反模式".在计算机科学领域,反模式（Anti-pattern）是一种被认为在特定环境、上下文或者执行情况下会导致问题、性能下降或者复杂性增加的解决方案或者设计方法.通常来说,反模式并没有绝对的"正确性",但是它们的实现方法可能不够高效或者会带来潜在的问题.

对于NoSQL来说,同样也存在一些反模式,因为NoSQL数据库和传统的关系型数据库不同,它们拥有着不同的适用场景和设计方法.今天这一节我们来讨论一下NoSQL反模式中的"文档数据库篇".

文档数据库反模式

很多情况下,我们在使用文档数据库时并没有精心的设计好Documents的结构,这样的话就会在后期出现很多困难.比如在更新Documents时如果需要修改结构或者添加字段,那么就会导致很多冗余代码或者可能需要全局修改等等问题.所以呢在使用文档数据库时,一定要认真设计好Documents的结构.

我们经常会将一些相关的数据嵌套在一个Document内,这样可以减少数据库查询的次数,提高效率.但是在大量嵌套的情况下会导致查询变得困难和低效.所以呢,在使用文档数据库时要尽量避免大量的嵌套关系.

示例说明

假设我们正在使用MongoDB作为我们的文档数据库.我们有一个Todo的应用程序,用于为用户的待办事项提供服务.我们需要设计一个Documents的结构来存储Todo的信息,并且要避免以上两个反模式.

以下是一个设计不佳的Documents结构：

{
   "_id": ObjectID("56f05d9c3a6ba01100ebf34a"),
   "title": "Buy Groceries",
   "category": "personal",
   "description": "Buy eggs, milk, bread and butter.",
   "completed": false,
   "dateAdded": "2016-03-21T08:08:12.841Z",
   "dateDue": "2016-03-25T08:08:12.841Z",
   "userId": "144348",
   "userDetails": {
}
  }
}

在这个Documents结构中,我们嵌套了用户的信息,这样会导致在查询时需要访问多个Documents,降低查询效率.

以下是一个遵循最佳实践的设计结构：

{
   "_id": ObjectID("56f05d9c3a6ba01100ebf34a"),
   "title": "Buy Groceries",
   "category": "personal",
   "description": "Buy eggs, milk, bread and butter.",
   "completed": false,
   "dateAdded": "2016-03-21T08:08:12.841Z",
   "dateDue": "2016-03-25T08:08:12.841Z",
   "userId": "144348",
   "userDetails": ObjectID("56f05d9c3a6ba01100ebf44a")
}

{
   "_id": ObjectID("56f05d9c3a6ba01100ebf44a"),
   "firstName": "John",
   "lastName": "Doe",
   "email": "john.doe@example.com",
   "phone": "+1 555-555-5555",
   "address": {
  "zip": "12345"
  }
}

在这个设计中,我们将用户的信息存储在单独的Document中,并使用userId来引用该用户的信息.这种方法不仅提高了查询效率,而且也避免了无限嵌套的问题.