. 面向文档存储 JSON风格的文件与动态模式使MongoDB简单而强大。 Schema Design：模式设计 在MongoDB中Schema的设计是非常不同于传统的DBMS。然而Schema是非常重要的，并且是建立应用程序的第一步。 在传统的数据模型中，给一个实体关系模型一个独立的用例在
.
面向文档存储
JSON风格的文件与动态模式使MongoDB简单而强大。
Schema Design：模式设计
在MongoDB中Schema的设计是非常不同于传统的DBMS。然而Schema是非常重要的，并且是建立应用程序的第一步。
在传统的数据模型中，给一个实体关系模型一个独立的用例在概念上是正确的，这是一个很正常的第三范式，但这通常会偏离你处于性能方面的考虑。在MongoDB中，Schema的设计不仅仅是对数据进行建模的用例。根据最常见的用例，我们对Schema的设计进行了优化，这有利有弊——用例通常是高性能的。然而有一个偏见是说Schema可能使某些动态查询相比于关系模型缺少一点优雅。
当我们要设计Schema时，需要考虑以下问题：
1.什么时候我们嵌入数据和链接(见下文)？我们在这里的决定讲影响第二个问题的答案
2.我们有多少集合，它们是什么？
3.什么时候我们需要原子操作？这些操作可以执行范围内的BSON文档，但并不是所有文档。
4.我们将创建什么索引使查询和更新快?
5.我们如何切分？什么是分片键?
Embedding and Linking：嵌入和链接
在设计一个MongoDB Schema时一个关键问题是什么时候嵌入，什么时候链接。嵌入是嵌套对象和数组到BSON文档中，服务器空间，链接是文档之间的引用。
在MongoDB中没有join——在1000服务器集群中做分布式join是很困难的。嵌入有点像“prejoined”(预连接)数据。
服务器处理在一个文档里面的操作是很容易的，美国空间，这些操作可以相当丰富。链接相比之下必须处理客户端应用程序，应用程序是通过发行一个后续查询来处理文档。
一般来说，实体之间有“包含”关系，则应该选择嵌入。当不使用连接会导致重复的数据，那么就选择使用链接。
Collections：集合
在MongoDB中集合类似于关系数据库中的表，香港空间，每一个集合包含文档，正如上面提到的这些文件可以相当丰富。在一个集合文档内字段是没有显式声明。然而来自于Schema设计师的一个关于那些字段将会是什么的概念，并且文档在集合内是怎样被结构化的。MongoDB不需要集合内的文档有相同的结构，然而在实践中大多数集合都是高度同质的。只要我们愿意我们就可以避免这些，例如当添加一个新字段，在这种情况一个“alter table”风格操作不是必要的。
Atomic Operations：原子操作
有些问题需要能够执行原子操作。例如，简单地增加计数器一个需要的原子性操作的案例。MongoDB还可以执行更复杂的操作,如下面所示的伪代码:
atomically { if( doc.credits > 5 ) { doc.credits -= 5; doc.debits += 5; } }
