從關系型數據庫轉移至NoSQL數據庫——比如從MySQL轉移到Couchbase，你需要對你的數據進行再思考。至于為什么是Couchbase而不是MongoDB什么的，因為博文的作者MC Brown是現任Couchbase副總裁，所以你懂得;同時這篇Couchbase博文還涉及到遷移后對查詢的影響。

以下為譯文：

如果你有一個建立在MySQL上的數據庫，你可能就會考慮是否需要以及更重要的如何將數據庫(和你的應用程序)轉移到Couchbase上。***的絆腳石不在Couchbase建立或者是存儲信息方面(盡管他們也很重要)，而是數據的重思，你需要使用另一種方式去處理你的數據，然后對應用程序作出相應的變化。

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

首先：數據結構的重思

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

下面看一個典型的例子，一個recipe(食譜)數據庫。因為Cheffy.com是建立在MySQL之上，所以MC Brown對此非常清楚?；A的表格結構是一個核心表，稱為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。

當然這種查詢方法很簡單，可以收集到一個食譜的所有信息。然而當你想給用戶演示這個食譜時，將會變得很復雜。你可以通過一個單獨的查詢來完成，然而有時候通過幾個查詢來完成這個更容易，分別獲取recipe、ingredients、metadata等表格的數據。在應用程序層，通過建立對象就可以自動的完成這些操作，同時這也是此類操作的基礎方法。

對于許多用戶和應用程序，通常會建立一個特殊的層去做這些事情，或者是選用一個對象映射系統將底層表格式的數據映射成應用程序使用的高等級對象。這里的recipe就是一個例子，在其它各種各樣的應用程序中也有類似的存在，包括invoicing (invoice、supplier、 destination, invoice lines) 和 blog posts (post content、keywords、creator、 comments)。

這種基于表格的解決方案本身并沒有什么問題，但是在這種場景下，key被跨表格的儲存，同樣這也意味著需要保持這幾個表格的同步。舉個例子，當某條記錄被刪除時會出現什么樣的情況?你必須刪掉連接到原表上的其它記錄(不管是手動刪除或者是級聯刪除)。類似的，當加載一個食譜信息時，你可能需要運行5-10個查詢。

Couchbase使用了一個不同的方法。取代將信息分割存入多張表格，在Couchbase中你只需要儲存一個單獨的結構(JavaScript Object Notation JSON)格式。JSON格式允許很多復雜的數據結構，包括字段、對象和標量類型，可以用它們組成一個完整的記錄。這就意味著你可以使用一個“文檔(document)”代替之前你使用多個表格來儲存實體(recipe，blog post)。

現在只需要在一處就可以對整個recipe進行操作，也就是只需要一個操作就可以從Couchbase數據庫中獲得你想要的信息。

這里對內容沒有強制的結構或者是定義，Couchbase數據庫中的任何文檔都可以儲存任何的信息和結構。然而你還可以使用一個驗證程序來檢查提供給數據庫文檔的結構，驗證可以同時針對字段以及字段的類容。

鑒于這里沒有嚴格的數據結構類型，它可以給存儲帶來更高的靈活性。舉個例子，你不需要額外的操作就可以向recipe文檔中添加新的部分“食譜的提供人”。

這里同樣沒有多重表這個概念，這里只有數據庫，數據庫中只包含了文檔。如果你想讓同一個數據庫支持各種不同類型的信息，你可以向文檔中加入字段。比如你可以如此來定義一個recipe：

那么type就可以作為標記在數據庫其它的地方使用，用以識別(選擇)你正在加載的數據。 #p# 

其次：如果什么都是文檔，那么你該如何查詢

***節中已經討論過如何在MySQL上使用一條簡單的SQL語句來獲得一個原料中包含胡蘿卜菜譜的列表。在MySQL中我們通過搜索ingredients表中與carrot匹配的recipe ID值，然后通過join從recipe表中獲得recipe title。出于速度考慮，你可能會使用一個索引來提升查詢的響應時間，用以保存單獨的每一條記錄。

在Couchbase所有數據都是文檔，并且這里也沒有嵌入的方法用以查詢表格中的字段，這里既沒有字段也沒有表格。因為Couchbase中本就沒有嚴格的數據結構模型(同樣也沒有方法讓數據庫引擎去確定自由格式文檔中的字段)，那么我們該如何完成在普通表格上的操作呢?

Couchbase支持一個構造稱為view，而這個view與MySQL中的view非常神似;除下在Couchbase中，view是唯一從數據庫文檔中獲得列表的方法，而在MySQL中view只是豐富了一個選擇。View事實上定義了3件事情：

View中包含的信息結構。你可以想象成表結構的定義，就像你在MySQL中建立一張表。

用以搜索的字段或者是信息。一個view將輸出兩項結果，key和value。Key將被傳入方法以發現你需要搜索什么，更具體的說就是你需要查詢的數據庫內容。

結構和key上的索引。索引同樣用于提升搜索的性能。

View使用JavaScript在一個設計文檔中進行定義，使用一個文檔作為參數的函數。一旦view被構造，數據庫中的每個文檔都會提供給view，然后view查詢并輸出你需要的結果。不用擔心JavaScript，JavaScript將只在服務器上執行(不會在客戶端上執行)。

現在回到MySQL，一個沒有where的查詢，查詢輸出選擇的字段，并且在輸出結果中構造一個匹配行的列表。下面，詳解一個SQL語句：

當在MySQL上運行一個查詢，MySQL服務器從一張或者多張表中取得信息，然后構建輸出結果列表：

在Couchbase中，View從單一的文檔中獲取記錄，并且在處理過程中附帶建立一個索引。結果則是view抓取的所有文檔列表。

在MySQL中執行一個帶where的查詢，索引一般被期望幫助你查詢需要的記錄：

而在Couchbase中，生成的view就是你的表格，當你對view進行查詢，Couchbase使用這些鍵的值(以及生成的相關索引)和過濾后(你指定)的返回信息，生成最終的匹配列表。

總結

上文主要針對MySQL到Couchbase的轉變，通過上面的兩個步驟基本上可以完成這個過渡。然而一些更高級的操作必然需要一些更多的思考，MC Brown在Couchbase博客同樣發布了轉換的第二部分，包括了更多高級查詢的思考。