从关系型数据库转移至NoSQL数据库——比如从MySQL转移到Couchbase，你需要对你的数据进行再思考。至于为什么是Couchbase而不是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。
当然这种查询方法很简单，可以收集到一个食谱的所有信息。然而当你想给用户演示这个食谱时，将会变得很复杂。你可以通过一个单独的查询来完成，然而有时候通过几个查询来完成这个更容易，分别获取recipe、ingredients、metadata等表格的数据。在应用程序层，通过建立对象就可以自动的完成这些操作，同时这也是此类操作的基础方法。