MySQL to NoSQL: Re-thinking of data and transformation of query mode

Moving from a relational database to a NoSQL database-for example, from MySQL to couchbase-you need to rethink your data. As for why Couchbase rather than http://www.aliyun.com/zixun/aggregation/13461.html ">mongodb what, because Bowen's author MC Brown is the current vice president of Couchbase, so you know, and this Couchbase blog also involves the impact of the migration on the query.

The following is the translation:

If you have a database built on MySQL, you may want to consider whether and more importantly how to transfer the database (and your application) to Couchbase. The biggest stumbling block is not couchbase building or storing information (although they are also important), but the reflection of data, you need to use another way to process your data, and then make the appropriate changes to the application.

Here's how to convert the MySQL database structure to couchbase Server and discuss how to change the query mode for two databases.

First: The re-thinking of data structure

MySQL (and other SQL types and a tabular database) forces you to make the data into forms. All your data is a table, and when you store complex structure type data, a single piece of data can be split into more than one table. For some applications and data types, it is a perfect logical and reasonable way to store data. For some applications, however, it is not appropriate to use such a method to store data.

Here's a typical example of a recipe (recipe) database. Because Cheffy.com is built on MySQL, MC Brown is very clear about this. The underlying table structure is a core table called recipe, which includes the recipe's name, subtitle, description, and servings. Of course, there are other recipe information, such as a list of ingredients (ingredients), method steps (methods), metadata (Metadata), and keywords (recipe) connected to the original Keywords table via a separate recipe ID. You can see these major parts in the following image:

This structure has some potential benefits, and some specific operations can be done very simply. For example, check out some recipe (recipes) that contain the principle "carrot (carrot)". You can look up "carrot" from the ingredients table and, given this, get a matching recipe list. By using join you can get a recipe list, get their title and some other information, use join to connect the recipe IDs in two tables by searching the ingredient table.

Of course, this kind of query method is very simple, can collect all the information of a recipe. However, when you want to show the user the recipe, it becomes very complicated. You can do this through a separate query, but 8630.html "> sometimes it's easier to do this through a few queries, and get data from recipe, ingredients, metadata, etc. At the application layer, these operations can be done automatically by creating objects, which is also the basis for such operations.

(Responsible editor: Fumingli)