溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家介紹MongoDB幾個問題梳理和復盤過程是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
工作中主要負責的系統主要以MongoDB數據庫為主，開發過程中積累了一些經驗和實際使用case，前一段時間把相關的場景整理了一下，組織了幾篇文章。
當我嘗試想把這些文發布到MongoDB中文社區時，與負責人溝通后，他們提出了一些文章中有待商榷和不嚴謹的地方，我在這里做一個梳理和復盤修正。
《MongoDB開發系列-從數據集合的設計開始 》中寫到
時間可以直接定義為格式化的時間，便于識別和查詢。不必特意存儲時間戳，這樣方便可視化的工具查詢核對。
這里的格式化的時間有歧義，會被認為是時間字符串，比如（2019-07-03 19:10:11），我的本意是想表達使用ISODate類型的時間格式存儲。
時間戳和時間格式兩個數據類型的存儲是一個選擇問題，有的人習慣使用時間戳存儲，有的人習慣用時間類型存儲。
建議存時間戳的認為，時間轉換成字符串很方便，字符串轉換成時間很不方便。還有效率的問題。
字段長度盡可能的短，不宜過長。也是考慮到內存優化。
原廠專家的建議是
實際并不存在長短的問題，因為有壓縮，字段名這種重復的字段壓縮后可以忽略
最開始我在考慮MongoDb是基于內存和key value形式的數據庫，關于【命名規范，短字符的建議】這一條，我在官方和社區都沒有找到正面的回應。
官方的文檔大多是以小寫命名做字段定義的，所以對于這個觀點 我也是在逐步否定，或者說這種做法對內存的優化并不明顯，反而犧牲了字段語意化，增加了開發字段映射和溝通成本。
官方文檔示例
正常的做法是：按照駝峰或者全部小寫的語義化命名即可
注意這種情況下，切忌文檔過寬。那如何避免這種情況，我的方法是預估最大字段數，以20個字段為節點，多于20則采用嵌套document的設計方式組織document。
這是工作中的設計經驗，有不嚴謹的地方，容易誤導讀者。不應該有20的這個量化數據，我的本意是，如果一級屬性太多，可以整理為二級嵌套字段，僅此而已。
關于MongoDB幾個問題梳理和復盤過程是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
