何時該更改數據庫後端？

Question

當存儲Web應用程序數據以知道應該使用哪個數據庫後端時，是否遵循一般的經驗法則？每天點擊次數，數據行數或其他指標是我在選擇時應該考慮的嗎？

我最初的想法是，這樣的順序看起來像下面的（但不一定，這就是爲什麼我問這個問題）。

1. 平面文件
2. BDB
3. SQLite的
4. MySQL的
5. PostgreSQL的
6. SQL服務器
7. 甲骨文

Answer 1

這並不那麼容易。唯一的一般經驗法則是當你現在無法跟上時你應該尋找另一種解決方案。這可能包括使用不同的軟件（不一定以全球固定的順序），硬件或體系結構。

使用類似memcached的緩存數據可能會比切換到另一個隨機存儲後端更有好處。

Answer 2

數據庫您的應用程序的使用率是最關鍵的人。主要是哪些查詢最常用（SELECT，INSERT或UPDATE）？

說如果你使用SQLite，它適用於較小的應用程序，但對於「web」應用程序，你可能是一個更大的應用程序，如MySQL或SQL Server。

您編寫腳本和Web應用程序平臺的方式也很重要。如果您正在Microsoft平臺上開發，那麼SQL Server是更好的選擇。

Answer 3

我認爲你的清單是主觀的，但我會玩你的遊戲。

平面文件

BDB

SQLite的

MySQL的

PostgreSQL的

SQL服務器

甲骨文

Teradata

Answer 4

如果您認爲您將需要其中一個重量級人員（SqlServer，Oracle），那麼您應該從開始之一開始。數據遷移非常困難。從長遠來看，只需從頂部開始並呆在那裏，就會降低成本。

Answer 5

通常情況下，我會使用我正在使用的任何框架通常接受的內容。因此，如果我在.NET中執行SQL Server，Python（通過Django或Pylons）=> MySQL或SQLite。

雖然我幾乎從不使用平面文件。

Answer 6

還有更多選擇只是「後端馬力」的RDBMS解決方案。例如，擁有承諾控制的能力，因此您可以回滾失敗的交易。原因。

除非您處於megatransaction rate應用程序中，否則大多數數據庫引擎都已足夠 - 因此它會成爲您想要爲軟件支付多少費用的問題，無論它是否在所需的硬件和操作系統環境中運行，以及你在管理軟件方面有什麼專長。

Answer 7

我認爲你的排名過於具體。對於非常小的數據集，您幾乎可以從平面文件等開始，然後轉到類似DBM的操作，稍微大一些，不需要類似SQL的語法，然後再轉到某種SQL數據庫。

但誰願意做所有重寫？如果應用程序將受益於訪問連接，存儲過程，觸發器，外鍵驗證等 - 只需使用SQL數據庫，而不考慮數據集的大小。

哪一個應該更多地依賴於客戶端的現有安裝以及可用的數據庫管理員技能，而不是您掌握的數據量。

換句話說，數據庫的大小遠非唯一的考慮因素，也許不是最重要的。

Answer 8

這種進展聽起來很痛苦。如果你要包括MS產品（特別是需要付費的SQL服務器）中有沒有什麼地方，你不妨使用整個堆棧，因爲你只需要支付在過去的這些：

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered). 

如果您最初將您的應用程序定位於SQL Server Compact，那麼您的所有SQL代碼都可以保證在不修改的情況下擴展到下一個版本。如果你比SQL Server Enterprise更大，那麼恭喜你。這就是他們所說的好的問題。

另外：回去檢查SO播客。我相信他們簡單地談到了這一點。

Answer 9

這個問題真的取決於你的情況。

如果你有過要部署到服務器控件，你可以安裝你需要的任何服務，那麼時間的安裝MySQL或MSSQL Express服務器和代碼對現有的數據庫架構VERSUS編碼針對平面文件結構不值得考慮的努力。

Answer 10

對此沒有一攬子答案，但總是使用平面文件不是一個好主意。你必須解析他們（我想），他們不能很好地擴展。從適當的數據庫開始，如Oracle或SQL Server（或MySQL，如果您正在尋找免費選項的話，Postgres）是一個好主意。對於很少的開銷，您將在以後節省很多精力和頭痛。它們還允許您以非愚蠢的方式構建您的數據，讓您可以自由地思考您將如何處理數據，而不是您將如何處理數據。

Answer 11

這實際上取決於您的數據，以及您打算如何使用它。在我以前的職位之一，我們使用Postgres由於本地地理位置和時區擴展，因爲它允許我們使用多邊形數據類型管理我們的數據。對我們來說，我們需要這樣做，我們也想使用存儲過程，視圖等。

現在，我工作的另一個地方是使用MySQL，只是因爲數據是規範化的，標準的逐行數據。

很久以來，SQL Server有4GB的數據庫限制（請參閱SQL Server 2000），但儘管存在此限制，但它仍然是清除舊數據的中小型應用程序的非常穩定的平臺。

現在，從與Oracle和SQL Server 05/08的合作中，我可以告訴你的是，如果你想讓穩定性，可伸縮性和靈活性得到豐厚的收穫，那麼這兩個是你最好的選擇。對於企業應用程序，我強烈建議他們（僅僅因爲這就是我們現在工作的地方）。

其他的事情要考慮：

• 語言集成（ASP.NET會話存儲，角色管理等）
• 查詢類型（SELECT，UPDATE，DELETE）雖然這更多的是一種模式的設計問題，而不是一個DBMS問題）
• 數據存儲需求

Answer 12

約火鳥什麼？那麼適合那個名單？

Answer 13

並且不要忘記您的解決方案的「客戶」必須具備的要求。如果你爲小公司編寫商業應用程序，那麼Oracle可能不是一個好的選擇......但是如果你爲一個必須在多個校區之間共享數據的大型企業編寫一個定製的解決方案，並且擁有一個好的IT部門，那麼Oracle與Sql Server的決定將歸結爲客戶最可能已經部署的內容。

現在的數據遷移並沒有那麼糟，因爲我們有Embarcadero提供的那些優秀工具，所以我會讓客戶需要推動這個決定。

Answer 14

如果您有選擇，SQL Server是go這個詞的不錯選擇，主要是因爲您可以訪問可靠的程序和功能，並且數據庫備份設施完全可靠。在數據庫本身（而不是您使用的任何語言）中儘可能多地包裝邏輯，這有助於提高安全性和性能 - 實際上，爲插入/更新邏輯始終使用過程提供了一個很好的參數，因爲它們使您不受注射攻擊。

如果我有選擇，那麼我認爲MySQL優先選擇一個大型的，相當簡單的數據庫主要用於讀取訪問。這不是爲了貶低MySQL，它已經有了明顯的改進，如果我沒有選擇，我會很高興地使用它，但是對於更復雜的系統來說，更新/插入活動通常是MSSQL的最佳選擇。