轉自：https://blog.csdn.net/zzq900503/article/details/70226211
MongoDB----數據結構---數據結構優化修改
在使用MongoDB開發的過程中，因爲它的方便性，很多數據都使用了內嵌文檔的形式保存。
但是這樣的結構在後期的開發過程中造成了很多問題。
深刻的體會到了，MongoDB可以不設計集合的結構和數據類型即可使用，但不代表它不需要數據結構設計。
一個好的系統運作，肯定需要對MongoDB的數據結構進行合理的設計才能高效運行。
當然，我也不建議在業務初期就進行嚴格的數據結構設計，因爲在開發初期業務變化快。可以在業務運行一段時間穩定，熟悉業務場景之後對MongoDB的數據結構進行優化調整。
主要考慮以下幾個方面:
不要嵌套太深
不要嵌套太深，否則讀取更新刪除起來會很複雜,最多一兩層。
業務類型的字段不要內嵌到基本實體中,而是使用關聯
比如我們有一個商品實體，我們想要給它增加一種圖表展示。
圖表展示就是我們的業務。
這種時候最好不要把圖表數據內嵌到基本實體中，隨着業務展示方式增多這樣會讓商品基本實體越來越混亂，而且不好清理。
修改也複雜，一條業務信息有變動，包含它的基本實體都需要修改。
因爲業務是經常變動的，有可能過一段時間就不用這種展示方式了。
所以最好是把業務信息新建實體。與基本實體建立關聯。這樣好管理和清除。
同時業務的操作不會影響到基本實體的信息。
如何合理建立關聯
關聯有四種方式:
它們都能解決業務實體變動所有包含它的基本實體都需要修改的問題。
一、基本實體引用業務實體
好處: 讀取方便，與內嵌在基本實體中的使用方式一樣get即可。
壞處:沒有解決基本實體越來越大，越來越混亂的問題，刪除業務實體麻煩。
二、基本實體保存業務實體ID
好處: 緩解基本實體越來越大，越來越混亂的情況。
壞處: 需要讀取兩次，刪除業務實體麻煩。
三、業務實體保存基本實體ID
好處:刪除清理方便，刪除業務實體後，關聯關係也隨着刪除
壞處:需要讀取兩次
四、新建關聯表
好處: 基本實體，業務實體數據清晰，不會變大。
壞處:需要讀取3次，刪除業務實體麻煩。
關聯關係保存在哪個實體中，需要考慮數量多少的問題，一般是被包含的數量少的 保存 在被包含數量多的 實體裏。
比如我有一個商品實體和一個版本實體。它們需要建立關聯。
因爲每個商品只可能屬於幾個版本，所以關聯信息保存在商品實體中只需要保存幾個版本的值即可。
但是每個版本可能含有成千上萬個商品，所以關聯信息保存在版本實體中，需要保存成千上萬個商品的值。應該避免這樣的關聯。
或者新建一個關聯表，關聯關係單獨存放，這樣的數據結構最清晰，但是讀取修改刪除都稍微麻煩一些。
---------------------
作者：張小凡vip
來源：CSDN
原文：https://blog.csdn.net/zzq900503/article/details/70226211
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！