首先，让我们先来了解一下什么是“反模式”。在计算机科学领域，反模式（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": "john.doe@example.com",
"phone": "+1 555-555-5555",
"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": "john.doe@example.com",
"phone": "+1 555-555-5555",
"address": {
"street": "123 Main St",
"city": "Anytown",
"state": "CA",
"zip": "12345"
}
}
在这个设计中，我们将用户的信息存储在单独的Document中，并使用userId来引用该用户的信息。这种方法不仅提高了查询效率，而且也避免了无限嵌套的问题。