设计数据库Schema是在已知数据库系统特性、数据本质以及应用程序需求的情况下为数据集选择最佳表述的过程。关系型数据库系统的Schema设计原则已经很完整了，在RDBMS中鼓励使用正规化的数据模型，这能帮助确保可查询性，避免对数据的更新造成数据不一致。而且，已有的这些模式能避免开发者产生疑问，比如如何建模一对多和多对多关系。但就算是在关系型数据库中，Schema设计也不是一门精确的科学。高性能要求的应用程序或者需要处理非结构化数据的应用程序可能会要求一个更通用的数据模型。一些应用程序对存储和伸缩性要求颇高，以至于要打破所有旧的Schema设计规则。FriendFeed就是一个很好的例子，这里有篇描述该站点非传统数据模型的文章值得一读，详见http://mng.bz/ycG3。
如果你来自RDBMS的世界，MongoDB的这种缺乏硬性Schema设计规则的做法可能会让你感到不太适应。虽然涌现出了一些好的实践，但对给定数据集的建模方法往往不止一个。本节的前提是其中介绍的原则能驱动Schema的设计，但现实情况是，那些原则都是可以变通的。在任何数据库系统中建模数据时，下面这些问题都值得考虑。
数据的基本单元是什么？在RDBMS中有带列和行的数据表。在键值存储中有指向不定类型值的键。在MongoDB中，数据的基本单元是BSON文档。
如何查询并更新数据？一旦理解了基本数据类型，我们需要知道如何操作数据。RDBMS有即时查询和联结操作查询。MongoDB也有即时查询，但不支持联结操作。简单的键值存储只能根据单个键来获取值。
根据允许的更新类型，数据库也有所区分。RDBMS中，可以使用SQL以复杂的方式来更新文档，将多条更新封装在一个事务中以获得原子性，还能回滚。MongoDB不支持事务，但它支持多种原子更新操作，这些操作可作用于复杂文档的内部结构。简单键值存储中，可以更新一个值，但通常每次更新都是将值完全替换掉。
其要点是构建最佳数据模型意味着理解数据库的特性。如果想在MongoDB里很好地建模数据，必须先理解它擅长于哪种查询和更新。
应用程序的访问模式是什么？除了理解数据的基本单元和数据库的特性，还需要明确应用程序的需求。如果你读了刚才提到的FriendFeed的文章，就会明白应用程序的特质能轻而易举地让Schema打破固有的数据建模原则。结论就是在确定理想的数据模型前，必须问无数个与应用程序有关的问题。读写比是多少？需要何种查询？数据是如何更新的？能想到什么并发问题？数据的结构化程度如何？
最好的Schema设计总是源于对正在使用的数据库的深入理解、对应用程序需求的准确判断以及过去的经验。本章的示例以及附录B中的Schema设计方式都将帮助你培养一种直觉，以便能出色地完成MongoDB中的Schema设计。学习了这些例子之后，你就能为自己的应用程序设计优秀的Schema了。