非規(guī)范化

非規(guī)范化數(shù)據(jù)不存儲(chǔ)規(guī)范化的數(shù)據(jù)。換句話說非規(guī)范化意味著相同數(shù)據(jù)的多個(gè)拷貝同時(shí)存在。

上一章中，我們在帖子中非規(guī)范化評論總數(shù)，以避免每次都加載所有的評論。在數(shù)據(jù)建模意義上說這是冗余的，因?yàn)槲覀兛梢酝ㄟ^計(jì)數(shù)每個(gè)評論，隨時(shí)計(jì)算出該總數(shù)（當(dāng)不考慮運(yùn)行速度）。

非規(guī)范化通常意味著額外的開發(fā)工作。在例子中，我們每次添加或刪除評論時(shí)，還需要同時(shí)更新相關(guān)的帖子，以確保 commentsCount 字段保持準(zhǔn)確。這就是為什么關(guān)系型數(shù)據(jù)庫，比如 MySQL，對這種做法不以為然。

但是，規(guī)范化做法也有其缺點(diǎn)：沒有 commentsCount 項(xiàng)，就象開始我們做的那樣，為了計(jì)算評論總數(shù)，每次我們都需要傳輸_所有_的評論。非規(guī)范化使我們能夠完全避免這種情況。

一份特殊發(fā)布

我們可以創(chuàng)建一個(gè)特殊的發(fā)布，送出我們有興趣的的評論數(shù)（通過聚合查詢服務(wù)器，我們目前能看到帖子的評論數(shù)）。

如果這樣發(fā)布代碼的復(fù)雜性不超過由非規(guī)范化造成的難度，它是值得考慮的...

當(dāng)然，這樣的考慮是和應(yīng)用相關(guān)的：如果你寫的代碼，數(shù)據(jù)完整性是非常重要的，那么避免數(shù)據(jù)的不一致，就比性能提升，更為重要和更有較高優(yōu)先級。

嵌入文件或使用多個(gè)集合

如果您是有 Mongo 的經(jīng)驗(yàn)，你可能會(huì)感到驚奇，我們給評論單獨(dú)創(chuàng)建了第二個(gè)集合：為什么不直接在帖子文檔中嵌入評論？

事實(shí)證明當(dāng)進(jìn)行集合操作時(shí)，Mongo 提供的許多工具會(huì)給我們帶來更好的結(jié)果。例如：

1. {{#each}} helper 遍歷游標(biāo)（collection.find() 的結(jié)果）是非常有效的。但是當(dāng)它遍歷一個(gè)較大文件中的對象數(shù)組時(shí)，效率就不高。
2. allow 和 deny 在 document 文檔級別上操作，因此可以很容易地確保每個(gè)評論修改的正確性，但是在帖子級別就會(huì)變得更復(fù)雜。
3. DDP 在文檔的頂級屬性級操作————這意味著，如果 comment 是 post 的一個(gè)屬性，每當(dāng)在帖子上創(chuàng)建一個(gè)新評論時(shí)，服務(wù)器就會(huì)將該帖子的整個(gè)更新的評論列表發(fā)送到每個(gè)連接的客戶端。
4. 在文檔級別更容易控制發(fā)布和訂閱。例如，我們想對帖子的評論進(jìn)行分頁，如果評論沒有屬于它們自己的集合，我們會(huì)發(fā)現(xiàn)很難做到。

Mongo 推薦嵌入文檔以減少昂貴的查詢次數(shù)。然而，考慮到 Meteor 的架構(gòu)，就不成問題了：大多數(shù)時(shí)候我們在客戶端查詢評論，其數(shù)據(jù)庫訪問基本上是沒有的。

非規(guī)范化的缺點(diǎn)

也有很好的理由使你不要非規(guī)范化數(shù)據(jù)。為了更好地理解反對非規(guī)范化的情況，我們推薦閱讀 Sarah Mei 寫的為什么你不應(yīng)該使用 MongoDB。