哪個數據庫適合我的應用程序mysql或mongodb？如何使用Node.js，骨幹，Now.js

Question

我想用 前端做出那樣docs.google.com的應用程序（不包括它的API，完全我自己的服務器上）：骨幹 後端：節點

什麼數據庫你會認爲更好嗎？ mysql或mongodb？應該支持良好的可擴展性。 我熟悉mysql與MySQL，如果答案是mysql，我會很高興。 但我看到很多教程，他們使用mongodb，爲什麼他們使用mongodb沒有mysql？ 我應該使用什麼？

任何人都可以給我鏈接一些示例應用程序（與源）使用骨幹，節點，MySQL（或mongo）構建。或至少應用程序。與節點和MySQL

感謝

Answer 1

用MongoDB的，你可以店 JSON對象並獲取他們完全成形，所以你並不真的需要一個ORM層，你花更少的CPU時間轉換數據來來回回。 MongoDB後面的開發人員也使得數據庫水平擴展爲更高的優先級，並允許您運行任意的Javascript代碼來預處理數據庫端的數據（允許數據的map-reduce樣式過濾）。

但是，您因這些收益而失去一些：您無法加入記錄。其實，你存儲JSON結構只能做到通過在SQL連接，但在MongoDB中，你只能有一個結構，以您的數據，而在SQL可以查詢不同，讓您的數據在可替代的方式更容易爲代表，因此，如果您需要對你的數據庫做很多分析，MongoDB會更難。

在我看來，MongoDB中的查詢語言比SQL更「粗糙」，部分原因是它不太熟悉，部分原因是查詢功能「隨意」放在一起，部分是因爲它使JSON有效，部分是因爲從字面上看，有兩種方法可以做同樣的事情，有些方法不像其他方法那樣有用或經常格式化。還有的數組和子對象類型在SQL的簡單的基於行的設計複雜性的增加，所以，語法必須能夠處理查詢包含您定義的值一些陣列，包含的所有您定義的值僅包含您定義的值，幷包含您定義的值的無。相同的區別適用於對象鍵和它們的值，這使查詢語法更難掌握。 （雖然我可以看到邊緣情況的需要，但是查詢參數（它接受在每個數據記錄上運行的javascript函數並返回一個布爾值）是Siren歌曲，因爲您可以輕鬆定義您想要的對象是否返回，但它必須在每記錄在數據庫上運行，沒有索引可以使用。）

所以，這取決於你想要做什麼，但既然你說這是爲了Google文檔克隆，你可能不關心任何表示，但文件表示，本身，你可能只會根據文件ID，文件名或所有者的ID /名稱查詢，也沒有複雜的查詢。

然後，我會說能夠接受用戶正在編輯的文檔的JSON表示，並將其放入數據庫並讓它自動索引這些重要字段，值得學習新數據庫的代價。

Answer 2

David提供了一個很好的答案。有幾件事要添加到它。

1. MongoDB的靈活性允許輕鬆實現敏捷/迭代開發。
2. 像node.js這樣的MongoDB本質上是異步的，並且在異步環境中工作得很好。
3. Mongoose是一個很好的ODM（對象文檔映射器），使得使用Node.js的MongoDB感覺很自然。與ORM不同，這是一個非常薄的層。

對於Google Doc功能，靈活性&由MongoDB提供的非常豐富的數據結構看起來更合適。

你可以通過搜索mongoose，node和MongoDB找到一些很好的示例文章。

這裏有一個同樣使用Backbone.js的和看起來不錯http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/

Answer 3

我也與這個選擇看使用的MongoDB因爲它是不適合建任務，創建的炒作掙扎。所以，我的2美分是：

1. 存儲和檢索分層對象，那你的文件可能是，是在MongoDB中更容易，因爲大衛說。如果你想存儲大於16Mb的文檔，它變得更加複雜 - MongoDB的答案是GridFS。

2. 組織文件夾，組，跟蹤哪些用戶擁有哪些文檔以及他/她提供對他們的訪問權限對於MySQL來說絕對容易 - 您擁有強大的SQL查詢和連接等優點，內置EXPLAIN優化，觸發器，函數，存儲過程等。MongoDB遠遠不夠。

那麼是什麼阻止你使用MySQL的都來組織文件和MongoDB存儲由ID（或多個集合 - 每個文件類型）標識的文檔一個收集？在我看來，最好的選擇是在一個應用程序中使用兩個數據庫，這確實不成問題。 MySQL將存儲用戶，組，文件夾，權限 - 無論你喜歡什麼 - 並且對於每個文檔，它將存儲對集合和文檔ID的引用（MongoDB具有特殊的格式 - DBRefs）。 MongoDB將自己存儲在集合中，如果它們都小於16MB，或者集合中的文檔的預覽和元數據以及GridFS中的整個文檔。