MongoDB資料模組化小案例：朋友圈評論内容管理

社交類的app需求，一般都會引入“朋友圈”功能，這個産品特性有一個非常重要的功能就是評論體系。

先整理下需求：

這個app希望點贊和評論資訊都要包含頭像資訊：

點贊清單，點贊使用者的昵稱，頭像；

評論清單，評論使用者的昵稱，頭像；

資料查詢則相對簡單：

根據分享id，批量的查詢出10條分享裡的所有評論内容；

跟據上面的内容，先來一個非常非常"樸素"的設計：

可以看到，<code>comment_ref_obj</code>與<code>praise_ref_obj</code>兩個字段，有非常重的關系型資料庫痕迹，猜測，這個系統之前應該是放在了普通的關系型資料庫上，或者設計者被關系型資料庫的影響較深。而在mongodb這種文檔型資料庫裡，實際上是沒有必要這樣去設計，這種模組化隻造成了多于的資料備援。

另外一個問題是，url占用了非常多的資訊空間，這點在壓測的時候會有展現，帶寬會過早的成為瓶頸。同樣username資訊也是如此，此類資訊相對來說是全局穩定的，基本不會做變化。并且這類資訊跟随評論一起在整個app中流轉，也無法結局”使用者名修改“的需求。

根據這幾個問題，重新做了優化的設計建議。

對比可以看到，整個結構要小了幾個數量級，并且可以發現url，usrname資訊都全部不見了。那這樣的需求應該如何去實作呢？

從業務抽象上來說，url，username這類資訊實際上是非常穩定的，不會發生特别大的頻繁變化。并且這兩類資訊實際上都應該是跟uid綁定的，每個uid含有指定的url，username。是最簡單的key，value模型。是以，這類資訊非常适合做一層緩存加速讀取查詢。

進一步的，每個人的好友基本上是有限的，頭像，使用者名等資訊，甚至可以在app層面進行緩存，也不會消耗移動端過多容量。但是反過來看，每次都到後段去讀取，不但浪費了移動端的流量帶寬，也加劇了電量消耗。

mongodb的文檔模型固然強大，但絕對不是等同于關系型資料庫的粗暴聚合，而是要考慮需求和業務，合理的設計。有些人在設計時，也會被文檔模型誤導，三七二十一一股腦的把資訊塞到一個文檔中。反而最後會帶來各種使用問題。