MySQL到NoSQL：資料的重思和查詢方式的轉換

從關聯式資料庫轉移至NoSQL資料庫——比如從MySQL轉移到Couchbase，你需要對你的資料進行再思考。 至於為什麼是Couchbase而不是HTTP://www.aliyun.com/zixun/aggregation/13461.html">MongoDB什麼的，因為博文的作者MC Brown是現任Couchbase副總裁，所以你懂得；同時這篇Couchbase博文還涉及到遷移後對查詢的影響。

以下為譯文：

如果你有一個建立在MySQL上的資料庫，你可能就會考慮是否需要以及更重要的如何將資料庫（和你的應用程式）轉移到Couchbase上。 最大的絆腳石不在Couchbase建立或者是存儲資訊方面（儘管他們也很重要），而是資料的重思，你需要使用另一種方式去處理你的資料，然後對應用程式作出相應的變化。

下面將著眼如何把MySQL資料庫結構轉換成Couchbase Server，並針對兩個資料庫的查詢方式改變進行討論。

首先：資料結構的重思

MySQL（以及其它的SQL類型並且以表格為基礎的資料庫）強迫你將資料打造成表格的形式。 你所有的資料就是一張表，當你儲存複雜結構類型資料時，一個單獨的資料片可能拆分成多於一張的表格。 對於一些應用程式以及資料類型，如此存儲資料是一個完美的邏輯以及合理的途徑。 而同樣對於某些應用程式，使用這樣的方法去存儲資料並不是很適合。

下面看一個典型的例子，一個recipe（食譜）資料庫。 因為Cheffy.com是建立在MySQL之上，所以MC Brown對此非常清楚。 基礎的表格結構是一個核心表，稱為recipe，包括了食譜的name、subtitle、description和servings。 當然還有一些其它的recipe資訊，比如：成分清單（Ingredients）、方法步驟（Method）、中繼資料（Metadata）以及通過一個獨立的recipe ID連接到原recipe表的關鍵字（Keywords）。 你可以在下圖中看到這些主要部分：

這個結構有一些潛在的好處，一些特定的操作可以非常簡單的完成。 舉個例子，比如說查詢一些包含原理「carrot（胡蘿蔔）」的recipe（食譜）。 你可以從Ingredients表中查找「carrot」，並鑒於這點得到一個匹配的recipe清單。 通過使用join你可以獲得一個recipe清單，從中獲取他們的title以及一些其它的資訊，通過搜索Ingredient表，使用join連接兩張表中的recipe ID。

當然這種查詢方法很簡單，可以收集到一個食譜的所有資訊。 然而當你想給使用者演示這個食譜時，將會變得很複雜。 你可以通過一個單獨的查詢來完成，然而8630.html">有時候通過幾個查詢來完成這個更容易，分別獲取recipe、ingredients、metadata等表格的資料。 在應用程式層，通過建立物件就可以自動的完成這些操作，同時這也是此類操作的基礎方法。

(責任編輯：fumingli)