如何擺脫現有關係資料庫的思想來設計 NoSQL 資料庫？

01-14

原本想將SQL Server變為MySQL,但後來覺得用Mongodb不錯，但是就怕自己思想不能轉變，想請教一下有類似經驗的人。當初轉變時候是如何設計的，經過一段時間後發現一些什麼問題？哪些是比較容易忽略的。有沒有相應簡單的一些解決方案？

前段時間我主導設計了公司新遊戲產品的服務端資料庫結構的設計。當時也是看文檔跟別人商量著做。我大概說下跟傳統關係型資料庫設計的差異。

mongodb 資料庫中可以存放比較複雜的數據結構。如果業務上沒有對屬性值做大量查詢的需求，可以把對象的屬性值存放到一個 collection 中。mongodb 是推薦這種屬性值嵌入的設計方式，這樣可以保證數據物理上連續，一次查詢不需要多次磁碟尋道，可提高查詢效率。

mongodb 也提供了關係型查詢介面，以及欄位索引；可以認為是Nosql 資料庫中對關係型查詢支持得很好的產品。

mongodb 的數據存儲是沒有固定表結構的(schema-less)，用的是類似於 json 的 bson(http://bsonspec.org/) 格式，也就是說數據中包含結構，包含欄位名。有個細節是，如果數據量大，欄位名就不要設計太長，因為這會增加存儲空間。

暫時就想到了這些。

參考 http://www.mongodb.org/display/DOCS/Schema+Design

從SQL Server變為MySQL，這沒多大問題，但從SQL Server或MySQL直接換為MongoDB，那問題就大了，這說明題主完全沒有弄清楚MongoDB到底是什麼，我甚至懷疑題主連SQL Server與MySQL都沒弄清楚。

所以，如果要換MongoDB，建議樓主一定要先弄清楚：

1.MongoDB是什麼？

2.SQL Server 或 MySQL是什麼？

然後，去了解最關鍵的問題：

3.SQL Server或MySQL與MongoDB的區別？其實題主的問題，就是在問兩者的區別。但要弄清楚區別，必須先弄清楚兩者各自是什麼。

我做一個簡單介紹：SQL Server 或 MySQL是傳統關係型資料庫，而MongoDB則是功能閹割版（減少功能來提高性能）。因此：

1.如果你的需求，需要用到某個功能，傳統關係型資料庫有，但MongoDB沒有，因此你就沒辦法用MongoDB來代替傳統關係型資料庫。

2.如果你的需求，兩者的功能都能滿足，那就學完MongoDB後，直接把業務用MongoDB實現一次就行了。

有個本質區別:

傳統的關係資料庫一般是簡單寫,複雜讀

而nosql 資料庫,一般是複雜寫,簡單讀

我想你不用擺脫,nosql不代表沒有關係,你需要的是按照用戶的訪問路徑設計好資料庫.冗餘是會經常用到的.

把mongodb當成一個大json對象處理，別老想著用了資料庫

表和表之間的外鍵關聯都不存在了. 取而代之的是json格式的類樹形結構. 這就是轉到mongodb之後最大的區別. 設計時把複雜的東西抽象成一個樹形結構,而不是像從前那樣先抽象成一個個實體,然後再抽象實體之間的關係. 個人感覺mongodb做設計比sql做設計要簡單很多. 總之,很多時候,轉到nosql是值得的.

可以參考：MongoDB資料庫設計中6條重要的經驗法則，part 1（每日一譯：2014-07-23）

關係是客觀存在的自然規律，擺脫就是在修改事實模型。

用NOSQL，我覺得可以理解成關係模型的變化，而不是另起爐灶。

James Phillips談從關係型資料庫轉到NoSQL 這篇文章可以參考

個人感覺是，如果數據只需要最新狀態，不在乎歷史數據，那麼NOSQL可以很好的完成需要，例如用戶當前指標：姓名，出生年月日，地點，級別，不需要歷史數據。永遠更新同一個json payload. 但似乎如果涉及到transactional 數據，感覺nosql不能很好的handle, 例如我幾天買了三次東西，買了什麼。。。明天買了4次。。。我在那裡買的，我是誰，要把這些放到一起，不清楚如何處理。

我遇到的苦難是，工程師已經轉向MongoDB,但是分析人員和產品經理還是停留在寬表的階段。中間缺少一個橋樑。雖然NOSQL是schema-less,但是最後消費這些數據的時候其實還是需要把所有的數據聯繫到一起的。