西瓜樂園
個人認為，MongoDB不太適合用作商城APP的數據庫：
能用是肯定能用的，但是不適合，開發過程中需要解決的問題會比較多且嚴峻；
單獨只使用MongoDB是不適合的，可以用它解決一部分的問題，也就是關係型數據庫和MongoDB配合著使用。
MongoDB是什麼，以及它的優點
概括地說一下MongoDB是什麼：它是一個基於分佈式文件存儲的非關係型數據庫；我們常見的MySQL、Oracle都是關係型數據庫，數據在關係型數據庫中都是通過表的格式展現，可以看做二維表格；而MongoDB中的數據，類似於JSON格式（BSON）。
MongoDB除了性能上的優勢之外，我認為最大的優點就是數據模式自由，如果你願意的話，可以將任何數據都保存到同一張表中（MongoDB中叫做Collection，等同於關係型數據庫中的Table）；
比如像這樣，一條客戶信息，一條產品信息，兩條毫無交集的數據，可以保存到同一個Collection中（比較極端的做法，實際使用的時候還是要區分開）：
為什麼說MongoDB不太適合用作商城應用的數據庫
首先，商城應用對事務一致性要求非常高，而MongoDB在事務的支持上，比較晚熟；MongoDB在3.0左右的版本，開始支持單文檔的事務，到了4.0以上的版本，開始支持多文檔事務；MongoDB發展的越來越好，但是在事務支持上，和關係型數據庫相比確實還是有差距。
第二，通常商城相關的業務，表結構相對都是比較成熟且固定的，比如客戶表、商品表、訂單表、支付表等等，同一個維度的數據結構基本都是相同的，比如客戶都會有姓名、手機號、收貨地址，這並沒有發揮MongoDB數據結構自由的優勢，關係型數據庫已經可以很好地支撐。
第三，MongoDB在多表關聯方面，優勢不大，比如需要查詢客戶下面所有的訂單，那麼可能需要關聯客戶表和訂單表；而讓MongoDB來實現，訂單可以作為客戶下面的一個子文檔來存儲，大概就是這個樣子：
總結來說，MongoDB更多適用於大數據量、高併發、弱事務、數據結構“隨意”且“善變”的場景，是對關係型數據庫的補充。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
剛好最近接觸的項目是一個商城項目並且使用了MongoDB數據庫。
該商城系統使用MongoDB的目的是存儲大量的商品信息，並且結合了搜索引擎lucene，以便於維護商品信息和進行查詢。
說明商城系統使用MongoDB不是稀奇的事情。
一分鐘瞭解MongoDB
MongoDB最大的特點是與MySQL等關係型數據庫不同的是，他是基於分佈式文件存儲的數據庫。它的存儲的數據格式是最接近自然最面向對象的Json格式。
最重要的是，MongoDB，不支持複雜事務和連表查詢。
請注意這一點也就意味著MongoDB的適用場景是有一定侷限性的，如果你想要複雜連表查詢和事務，那麼MongoDB將做不到。
如果你是想維護單表信息並且做頻繁得更新和查詢，而且數據量增長指數很嚇人，MongoDB非常適合。
宇文氏建議:
這也就意味著如果MongoDB用於電商系統，那麼很可能作為其中的一個數據存儲部分，多半會和MySQL等數據庫聯合使用。
關注“極客宇文氏”，一名有料的軟件工程師。極客宇文氏
首先，mongdb一個最大的缺點就是不能進行多表聯合查詢，也就是說像mysql等關係型數據庫裡面的join語法在mongdb是不存在的。所以說如果你想要的數據確保在一張表裡就能查出來就還好，如果涉及到多表的話難道你想用各種for循環去實現表的聯合查詢嗎？
而實際上商城系統還是比較複雜的，業務不可能用一張表來表達，肯定會涉及到多表查詢，因此mongdb可以用在商城系統中的一環，但是不能用於全部。
IT我的小熊不見了丶
這個問題要看是什麼樣的商城？如果是作者可以小東西，商城非常簡單，那還是可以的。現在比較火的前後端分離，以及全棧工程師，從前端寫到後端，老顧看到有些視頻和文章就是用MongoDB作為數據庫進行開發的。
因地制宜
真實已經運營上線的商城系統是比較複雜的，設計到的技術點也是比較多的。好的系統不會只選擇一種方案，而是遇到什麼業務場景，選擇不同的方案。
持久化方案
我們這裡溝通一下持久化方案。小夥伴們經常掛到嘴邊的數據庫其實就是一種持久化方案，把數據保存到磁盤上面。經常用到的產品如：oracle，mysql，MongoDB，elasticsearch，hdfs，甚至redis都是。
不同的持久化產品有不同的特性，mongoDB採用的是kv存儲的方式，高性能，天生支持分佈式，常常是用來做數據分析的。他的弱點就是關聯查詢就比較麻煩。
而傳統的mysql數據庫關聯查詢就比較方便，但性能不高，搭建集群也比較麻煩。
總結：要看具體的業務場景，選擇不同的持久化方案；不能脫離了業務，脫離業務就是耍流氓了。
老顧聊技術
不適合，mongo適用於字段類型複雜且經常變化的業務，如社交系統，行為數據，爬蟲等。商城的特點是schema固定，強事務和一致性，關聯查詢頻繁。這些都非nosql的特長
烏里雅蘇臺Uriahsutai
性能不如mysql，唯一的好處就分佈式方便，只能用來做日誌系統，計算用的大數據存儲。要不還是乖乖用MySQL吧，一個稍微複雜點的查詢性能可以比mysql慢十多倍。 另外一點好處就是寫入特快，不會因為單表數據越來越多就越來越慢。只合適做低頻查詢的數據存儲
小小CTO
非常不推薦，mongo的話是文檔型非關係型數據庫，弱化了對象的概念，像這種大型的系統還是推薦mysql這種關係型數據庫，mongo的話，你在使用的過程中，維護這些表的相互關係，時間上會花掉更多的時間。
蘭州拉麵首席刀客
[靈光一閃]主要還是事務機智不理想。
半寸灰1
可以的，也有實際案例。
corder
不支持事務就決定它在核心功能上不合適
