2.2　集合

集合就是一組文檔。如果將文檔比作關系數據庫中的行，那么一個集合就相當于一張表。

2.2.1　動態模式

集合具有動態模式的特性。這意味著一個集合中的文檔可以具有任意數量的不同“形狀”。例如，以下兩個文檔可以存儲在同一個集合中：

{"greeting" : "Hello, world!", "views": 3}
{"signoff": "Good night, and good luck"}

需要注意的是，以上文檔中的鍵、鍵的數量以及值的類型都是不同的。由于任何文檔都可以放入集合中，因此經常會出現這樣的問題：“為什么還需要多個集合呢？”既然不同類型的文檔不需要區分模式，為什么還要使用多個集合呢？有以下幾點原因。

• 對于開發人員和管理員來說，將不同類型的文檔保存在同一個集合中可能是一個噩夢。開發人員需要確保每個查詢只返回特定模式的文檔，或者確保執行查詢的應用程序代碼可以處理不同類型的文檔。如果在查詢博客文章時還需要剔除包含作者數據的文檔，那么這會非常麻煩。
• 獲取集合列表比提取集合中的文檔類型列表要快得多。如果在每個文檔中都有一個 "type" 字段來指明這個文檔是“skim”“whole”還是“chunky monkey”，那么在單個集合中查找這 3 個值要比查詢 3 個相應的集合慢得多。
• 將相同類型的文檔放入同一個集合中可以實現數據的局部性。相對于從既包含博客文章又包含作者數據的集合中進行查詢，從一個只包含博客文章的集合中獲取幾篇文章可能會需要更少的磁盤查找次數。
• 在創建索引（尤其是在創建唯一索引）時，我們會采用一些文檔結構。這些索引是按照每個集合來定義的。通過只將單一類型的文檔放入集合中，可以更高效地對集合進行索引。

創建模式并且將相關類型的文檔放在一起是非常合理的。雖然默認情況下為應用程序定義模式并非必需，但這是一種很好的實踐，可以通過使用 MongoDB 的文檔驗證功能和可用于多種編程語言的對象–文檔映射（object-document mapping）庫來實現。

2.2.2　命名

集合由其名稱進行標識。集合名稱可以是任意 UTF-8 字符串，但有以下限制。

• 集合名稱不能是空字符串（""）。
• 集合名稱不能含有 \0（空字符），因為這個字符用于表示一個集合名稱的結束。
• 集合名稱不能以 system. 開頭，該前綴是為內部集合保留的。例如，system.users 集合中保存著數據庫的用戶，system.namespaces 集合中保存著有關數據庫所有集合的信息。
• 用戶創建的集合名稱中不應包含保留字符 $。許多驅動程序確實支持在集合名稱中使用 $，這是因為某些由系統生成的集合會包含它，但除非你要訪問的是這些集合之一，否則不應在名稱中使用 $ 字符。

子集合

使用 . 字符分隔不同命名空間的子集合是一種組織集合的慣例。例如，有一個具有博客功能的應用程序，可能包含名為 blog.posts 和名為 blog.authors 的集合。這只是一種組織管理的方式，blog 集合（它甚至不必存在）與其“子集合”之間沒有任何關系。

盡管子集合沒有任何特殊屬性，但它們很有用，許多 MongoDB 工具整合了子集合。

• GridFS 是一種用于存儲大型文件的協議，它使用子集合將文件元數據與內容塊分開存儲（有關 GridFS 的更多信息，請參閱第 6 章）。
• 大多數驅動程序為訪問指定集合的子集合提供了一些語法糖。例如，在數據庫 shell 中，使用 db.blog 可以訪問 blog 集合，使用 db.blog.posts 可以訪問 blog.posts 集合。

在 MongoDB 中，使用子集合來組織數據在很多場景中是一個好方法。