MongoDB----資料結構---資料結構優化修改
阿新 • • 發佈：2019-01-26
在使用MongoDB開發的過程中，因為它的方便性，很多資料都使用了內嵌文件的形式儲存。
但是這樣的結構在後期的開發過程中造成了很多問題。
深刻的體會到了，MongoDB可以不設計集合的結構和資料型別即可使用，但不代表它不需要資料結構設計。
一個好的系統運作，肯定需要對MongoDB的資料結構進行合理的設計才能高效執行。
當然，我也不建議在業務初期就進行嚴格的資料結構設計，因為在開發初期業務變化快。可以在業務執行一段時間穩定，熟悉業務場景之後對MongoDB的資料結構進行優化調整。
主要考慮以下幾個方面:
不要巢狀太深
不要巢狀太深，否則讀取更新刪除起來會很複雜,最多一兩層。
業務型別的欄位不要內嵌到基本實體中,而是使用關聯
比如我們有一個商品實體，我們想要給它增加一種圖表展示。
圖表展示就是我們的業務。
這種時候最好不要把圖表資料內嵌到基本實體中，隨著業務展示方式增多這樣會讓商品基本實體越來越混亂，而且不好清理。
修改也複雜，一條業務資訊有變動，包含它的基本實體都需要修改。
因為業務是經常變動的，有可能過一段時間就不用這種展示方式了。
所以最好是把業務資訊新建實體。與基本實體建立關聯。這樣好管理和清除。
同時業務的操作不會影響到基本實體的資訊。
如何合理建立關聯
關聯有四種方式:
它們都能解決業務實體變動所有包含它的基本實體都需要修改的問題。
一、基本實體引用業務實體
好處: 讀取方便，與內嵌在基本實體中的使用方式一樣get即可。壞處:沒有解決基本實體越來越大，越來越混亂的問題，刪除業務實體麻煩。
二、基本實體儲存業務實體ID
好處: 緩解基本實體越來越大，越來越混亂的情況。壞處: 需要讀取兩次，刪除業務實體麻煩。
三、業務實體儲存基本實體ID
好處:刪除清理方便，刪除業務實體後，關聯關係也隨著刪除壞處:需要讀取兩次
四、新建關聯表
好處: 基本實體，業務實體資料清晰，不會變大。壞處:需要讀取3次，刪除業務實體麻煩。
關聯關係儲存在哪個實體中，需要考慮數量多少的問題，一般是被包含的數量少的 儲存 在被包含數量多的 實體裡。
比如我有一個商品實體和一個版本實體。它們需要建立關聯。
因為每個商品只可能屬於幾個版本，所以關聯資訊儲存在商品實體中只需要儲存幾個版本的值即可。
但是每個版本可能含有成千上萬個商品，所以關聯資訊儲存在版本實體中，需要儲存成千上萬個商品的值。應該避免這樣的關聯。
或者新建一個關聯表，關聯關係單獨存放，這樣的資料結構最清晰，但是讀取修改刪除都稍微麻煩一些。