NoSQL反模式 – 文档数据库篇

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

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

文档数据库反模式

1.没有设计好Documents结构

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

2.使用大量的嵌套关系

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

示例说明

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

示例1：

以下是一个设计不佳的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": {
      "firstName": "John",
      "lastName": "Doe",
      "email": "[e-mail]",
      "phone": "[phone]",
      "address": {
         "street": "123 Main St",
         "city": "Anytown",
         "state": "CA",
         "zip": "12345"
    }
  }
}

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

示例2：

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

{
   "_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": "[e-mail]",
   "phone": "[phone]",
   "address": {
      "street": "123 Main St",
      "city": "Anytown",
      "state": "CA",
      "zip": "12345"
  }
}

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