設計數據庫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了。