SQL vs NoSQL：如何選擇？

在前一篇文章中，我們讨論了 sql 與 nosql 資料庫之間基本的差別。接下來，我們我們将應用我們在特定場景中的知識來确定最佳的選擇。

回顧一下：

sql 資料庫:

nosql 資料庫

sql 資料庫是一個理想的項目，确定好了需求和健壯的資料的完整性是至關重要的。nosql 資料庫是無關理想，不确定的或者不斷變化的資料需求 ，在速度和可伸縮性上更重要。 簡單的術語：

一些項目要精準的符合。如果你有較淺的話，任何一種選擇都是可行的，或者自然的非規範資料。但是請注意這些簡化示例場景與全面的概括！你比我更了解你的項目，我不建議切換從sql到nosql或反之亦然，除非它提供了可觀的效益。這是你的選擇。在項目的開始要考慮利弊,你不能出錯。

讓我們重新發明輪子，實作一個基于sql的通訊錄系統。我們最初接觸表的時候，天真的定義以下字段：

問題一: 很少人隻有一個電話号碼。我們可能需要至少三個号碼：一個座機，一個行動電話，一個工作電話。但是有多少個号碼無關緊要——有些人、有些地方需要更多。讓我們建立一個單獨的 telephone 表，這樣的話他們想要多少聯系人都可以。這也讓我們的資料标準化了——我們不需要沒有号碼的聯系人顯示為null。

問題二：email位址有同樣的問題，是以我們也建立一個類似的 email 表：

問題三：我們可能不想輸入一個（地理位置的）位址，或者我們想輸入多個位址，工作地，家裡，度假住所等。是以我們需要一個新的 address 表：

我們原來的 contact 表簡化成：

太棒了——我們有了一個能存放任意聯系人的任意多個電話号碼，email 位址和住址的标準化資料庫。不幸的是……

我們沒有考慮到聯系人的中間名字、出生日期、公司或職位。我們添加多少字段都沒關系，我們很快會受到更新的需求要添加備注、紀念日、關系狀态、社交媒體賬号、内腿測量值、最喜歡的奶酪類型等字段。預測所有選項是不可能的，是以我們可能需要一個 otherdata 表，用來處理名字-值對。

對開發者或者系統管理者來說，檢查資料庫并不容易。程式邏輯會變得更慢、更複雜，因為利用單個 select 和多個 join 語句查詢聯系人資料不太實際。(你可以這麼做，但是結果可能需要包含 telephone，email，和 address字段的每一種組合：如果有個聯系人有三個電話号碼，五個email位址和兩個住址，那麼sql查詢将會産生30條結果。) 最後，全文搜尋很困難。如果有人輸入字元串"sitepoint"，我們必須檢查所有的表，看看它是否為聯系人名字、電話、email或者住址的一部分，并且需要做相應的排序。如果你用過wordpress的搜尋功能，你就會明白這有多虐心。

我們的聯系人資料關注的是人。他們難以預測，在不同的時間有不同的需求。使用nosql資料庫，聯系人清單将會從中受益。資料庫将一個聯系人的所有資料存儲在一個單獨的文檔裡的contacts 集合裡。

在這個例子裡，我們沒有存儲聯系人的頭銜或者性别，我們還添加了一些資料，而這些資料不需要應用到任何其他聯系人。沒關系——我們的nosql資料庫不會介意，我們還可以随意添加或移除字段。

由于聯系人資料在單獨的文檔裡，我們可以用一條查詢語句擷取一部分或全部資訊。全文搜尋也變得簡單；在mongodb裡，我們可以這樣定義 contact 中的所有文本字段的索引：

然後執行全文搜尋：

社交網絡可能使用類似的聯系人資料存儲，但是它會根據功能集合擴充，比如關系鍊、狀态更新、發送消息和”贊“。這些功能可能會根據使用者需求來實作或者移除——無法預測它們會怎樣演進。

另外:

nosql看來是個好的方案。它允許我們快速地實作存儲不同類型資料的功能。例如，可以用單個文檔裡的 status 集合替換所有使用者的過時的狀态更新。

文檔可能會變得很長，但我們可以擷取數組的子集，比如最近的更新。每個使用者的所有的曆史狀态記錄都能被快速搜尋到。

現在假設我們想在釋出更新的時候引入表情符号選擇。這涉及到給 update 數組裡的新記錄添加圖引用。不像 sql 存儲，沒必要把之前消息裡的表情符号置為 null——我們的程式邏輯可以顯示預設圖檔或者沒有圖檔，如果沒有設定表情符号的話。

考慮一個監控倉庫貨物的系統。我們需要記錄：

我們的資料需求：

通用的物品資訊，比如包裝數量、尺寸和顔色等可被存儲，但這些是我們可以識别并應用到任何物品上的離散資料。我們不太可能關注細節，例如筆記本處理器速度或者智能手機的電池壽命。

最小化出錯的可能是必要的。我們不能讓物品憑空消失或者移到已經有别的物品存放的位置。

簡單來說，我們在記錄物品從一個實體區域到另一個實體區域的轉移——或者從a位置移走，放到b位置。這是同一個動作的兩次更新。

我們需要一個具備強制資料完整性和事務支援的健壯存儲系統。（目前）隻有 sql 資料庫滿足這些需求。

我希望這些場景有所幫助，但是每個項目是不同的，最終，你需要做出自己的決定。(雖然，我們開發人員擅長于證明我們的技術選擇，不管他們有多好!)

最好的建議:顯露你自己盡可能多的技術。這些知識可以讓你對sql或者nosql做出一個理性和情感上公正的判斷。祝您好運。