MongoDB適合做商城app數(shù)據(jù)庫嗎？首先，mongdb一個最大的缺點就是不能不能接受多表同盟網站查詢，也就是說像mysql等關系型數(shù)據(jù)庫里面的join語法在mongdb是不存在地的。因此說如果你是

MongoDB適合做商城app數(shù)據(jù)庫嗎？

首先，mongdb一個最大的缺點就是不能不能接受多表同盟網站查詢，也就是說像mysql等關系型數(shù)據(jù)庫里面的join語法在mongdb是不存在地的。因此說如果你是想的數(shù)據(jù)必須保證在三張表里就能查出來就而且，假如不屬于到多表的話你以為你想用各種for循環(huán)去實現(xiàn)方法表的組織去查詢嗎？

而事實上購物系統(tǒng)應該都很緊張的，業(yè)務不可能用一張表來怎樣表達，肯定會比較復雜到多表去查詢，因此mongdb是可以用在商城系統(tǒng)中的一環(huán)，但沒法主要是用于全部。

結構設計三原則？

架構設計三原則：

比較好原則

簡單點原則

演化出原則

一、合適原則

架構設計的幾個誤區(qū)：

1.最不流行架構

微服務很火，是不是立即把帶的多多的springmvc改成微服務架構？docker很火會不會立刻再次進入容器？

2.離棄一線大廠

我們在做電商，淘寶是一線大廠，要不要然后采用淘寶架構？開放源代碼了消息隊列中間件，我們社交的也再快速切換吧？

3.去追求大而全

我們與此同時業(yè)務展開攻擊用戶量會進階馬上，我們要兼容微服務擴展，要加入到消息隊列，數(shù)據(jù)庫主從，一并加入Elasticsearch都有利與后期網上查詢，另外不斷系統(tǒng)分布式部署，要參加docker來系統(tǒng)管理環(huán)境，日志管理要上kafka等等。

左右吧幾點，的確都是錯的，畢竟我們選型遠離目標的最主要的矛盾，為我們奇特的業(yè)務場景，訂制適合的系統(tǒng)架構，在用最流行的的架構，有什么判斷我們業(yè)務特殊性？真接永遠追隨大廠還有沒有考慮到我們團隊的技術能力和有無真有能遇到大廠那種極端化場景？追求大而全是否是讓不足的團隊資源陷入瘋狂無邊的低產出工作上？架構應該是取和舍，不求哪個網站，不求很全，愿最合適。

二、簡單的原則

緊張，就那樣的話難度減少，不可控風險增強，盡量很簡單，能系統(tǒng)方便理解，方便啊擴展，耦合度降低。很簡單的確華指沒有技術含量，反到很簡單實現(xiàn)程序更為實惠，比花哨設計更能不適應系統(tǒng)一步步演變。

三、演化原則

羅馬并非幾天完工的，也并非一天的新出聲的。我們要做高內聚低耦合設計，就是是為可擴展。但我們也要避過使用過度電腦設計，盡量的避免根本不絕對不會遇到的場景投入使用過度資源，設計應該是舍取，正經地方，集中資源做通常的事，接著參照未來的方向，不斷地重新架構系統(tǒng)優(yōu)化，也就會衍生出出都行吧本業(yè)務的工程。