MongoDB Combat-Document-oriented data (find the most appropriate way to model your data)

I have been studying the MongoDB database through Ruby for a while, and in the course of learning, I have also shared the process of learning and growing, and I have written two introductory articles and 12 advanced articles. At the beginning of this article, we will enter the actual operational process of MONGODB, a non-relational database of MongoDB-a document database that stores document-oriented data.

1. How to use schema in a MongoDB database

Designing a database schema is the process of choosing the best representation of a dataset in the context of known database system features, data nature, and application requirements. The traditional relational database RDBMS encourages the use of a normalized data model to ensure the data is queryable and to address inconsistencies in data updates. But the design of the schema is not a precise science. A common data model may be required when an application is required to process unstructured data, or if the application has high performance requirements. There is a lack of hard schema design rules in MongoDB.

In order to be able to refer to the schema design rules of the traditional RDBMS, we first need to clear the RDBMS and MongoDB in the following three aspects of the corresponding relationship and the corresponding differences:

• What are the basic units of data?

  In RDBMS, the basic unit of data refers to a data table with columns and rows;

  A key that points to an indeterminate type value in the key-value store;

  In MongoDB, the basic type of data is the Bson document

• How do I query and update data?

  In the data query operation:

  RDBMS supports instant query and join operation queries;

  MongoDB supports instant queries, but does not support junction operations;

  Simple key-value storage can only get values based on a single key

  In the Data update operation:

  RDBMS, you can use SQL to update the document in a complex way, encapsulating multiple updates in a single transaction for atomicity and rollback;

  MongoDB does not support transactions, but supports a variety of atomic operations that can be used in the internal structure of complex documents;

  In a simple key-value store, you can update a value, which is usually replaced completely by each update.

• What is the access mode for the application?

  To determine an ideal data model, you have to ask countless application-related questions. Read/write ratio? What kind of query do you need? How is the data updated? Concurrency issues? What is the degree of data organization?

Overall, the best schema design always stems from an in-depth understanding of the database being used, accurate judgment of the application requirements, and past experience.

2. Actual combat-design e-commerce data model

In this section, we'll show you how to model e-commerce data in MongoDB, and we'll focus on products and classifications, users and orders, and product reviews. For many developers, data modeling is always accompanied by object mappings. Using the object mapper facilitates validation, type checking, and correlation. MongoDB has no object mapping needs, on the one hand because the document is already a similar object of the expression, while the driver for MongoDB provides a fairly high-level interface, referring to the pre-order blog post learning, using the driver interface to build a complete application on MongoDB. Many mature MongoDB Object mappers provide an additional layer of abstraction on top of the basic language driver.

Because ultimately it is necessary to deal with the document, to focus on the document itself, to recognize the design of a well-designed MONGODB schema of the document, so that we can better use the database.

2.1 Products and classifications

Products and classifications are information that will appear on any e-commerce site. In traditional RDBMS, products use a large number of data tables, such as tables that store basic information, tables that store associated shipping information and price history, and other complex properties that may occur. This multi-table schema is useful with the help of RDBMS table-coupling capabilities.

In a MongoDB database, however, modeling a product is relatively straightforward. The collection does not necessarily have schema. Any product information document can accommodate the various dynamic properties required by the product. By using arrays to accommodate the internal document structure, you can also describe multiple tables in an RDBMS as a MongoDB collection.

Here is an example product from a gardening store

Doc={   _id:new objectid ("59884b76b53fab2a8024b6ad"),    slug: " wheel-barrow-9092 ",    sku:" 9092 ",    name:" extra large wheel  Barrow ",    description:" Heavy duty wheel barrow ",    details:{        weight:47,       weight_unite: " 1bs ",       model_num:40392882,        Manufacturer: "Acme",        color: "Green"    },    total_review:4,   average_review:4.5,   pricing:   {      retail:589700,     sale:489700   },    price_history:[   {   retail:529700,   sale:429700,    start:new date (2010,4,1),    end:new date (2010,4,8)    },   {   retail : 529700,   sale:529700,   start:new date (2010,4,9),    end: New date (2010,4,16)    }   ],   cateory_ids:[     new objectid ("59884ee3b53fab2a8024b6ae"),     new objectid (" 59884ee3b53fab2a8024b6af ")    ],   main_cate_id:new objectid (" 59884ee3b53fab2a8024b6b1 "),    tags:[" Tools "," gardening "," Soil "]}

Here, if you are generating a URL for a document, it is generally recommended that you set a short name field. And the field should have a unique index, so that the value in it can be used as the primary key. Assuming that the document is stored in the Products collection, you can create a unique index as follows.

Db.products.ensureIndex ({slug:1},{unique:true})

Because a unique index exists on the slug, you need to use Safe mode when inserting the document, so you know whether the insert is successful or not. Executing the Insert code in Ruby

@products. Insert ({:name=> "Extra Large Wheel Barrow",:sku=> "9092",:slug=> "wheel- barrow-9092 "},: Safe=>true)

:safe=>true; in code if the insert succeeds, the exception is not thrown, indicating that a unique short name is selected, and if an exception is thrown, the code needs to retry with a new short name. Subsequent storage of details-details for different products in the above documents, followed by the storage of the current price pricing and the historical price price_history,category_ids an array of tag names stored.

RDBMS databases can use join operations to make multi-table federated queries. As a MongoDB database that does not support join queries, how do you support many-to-many strategies? The document stores the Category_ids array, which contains an array of object IDs, each of which is a pointer to the _ID field of a classified document. The following is a demonstration of a categorized document:

Doc={     _id:new objectid ("59884ee3b53fab2a8024b6ae"),      slug: "Gradening-tools",     ancestors:[     {         name: "Home",         _id:new  objectid ("59884ee3b53fab2a80240003"),         slug: "Home"       },     {        name: "Outdoors",         _id:new objectid ("59884ee3b53fab2a80240001"),         slug: "Outdoors"      }      ],     parent_id:new objectid ("59884ee3b53fab2a80240001"),      name: "Gardening tools",      description: "Gardening  gadgets galore "} 

Observe the object ID in the Category_ids field of the product document and discover that the product is associated with the gardening tools category. Putting the Category_ids array key in the product documentation makes it possible for many-to-many queries.

Query all products in the Gardening tools category

Db.products.find ({category_ids=>category{' _id '}})

Querying all the classifications for a specified product, you can use the $in operator, which resembles the in directive for SQL.

Db.categories.find ({_id:{$in:p rocuct[' Category_ids '}})

In the classification document, the meaning of storing the parent document array is to formalize and place the name of the ancestor classification into the document of each sub-category, which is also because MongoDB does not support the associated query. This way, when querying gardening tools classifications, there is no need to perform additional queries to get the names and URLs of the parent category (Outdoors and home).

2.2 Users and Orders

See how to model users and orders to illustrate another common relationship-a one-to-many relationship. A user may have more than one order. In an RDBMS, foreign keys are used in the order table, and conventions are similar in MongoDB, such as:

Doc={  _id:new objectid ("6a5b1476238d3b4dd5000001"),   user_id:new objectid (" 4a5b1476238d3b4dd5000001 "),   state:" CART ",  line_items:[{       _id:new objectid ("4a5b1472134d3b4dd5000921"),       sku: "9092",       name: "Extra large wheel barrow",       quantity:1,      pricing:{           retail:5897,          sale:4897,            }  },  {       _id:new objectid ("4a5b1472134d3b4dd5000922"),       sku: "10027",       name: "Rubberized work glove,block",       quantity:2,       pricing:{          retail:1499,           sale:1299,            }  }  ],  shipping_address:{     street: "588 5th street",     city: "Brooklyn",     state: "NY",     zip:11215   },  sub_total:6196}

The second attribute in the order user_id holds a user's _id, which is a pointer to the sample user. Such a design makes it easy to query any party in the relationship. To find all orders for a user:

Db.orders.find ({user_id:user{' _id '}})

The user who wants to get the specified order is also simple:

user_id=order[' user_id ']db.users.find ({_id:user_id})

The above order presentation has obvious advantages, first of all, it is easy to understand, the complete order concept can be encapsulated in an entity, including the item details, shipping address and the final payment information. When querying a database, you can return the entire order object through a simple query. Second, the product in the purchase of information stored in the order document, so that can easily query and modify the order information.

The user's document also uses a similar pattern. A list of address documents and a list of payment methods are saved. At the top of the document, you can also find basic properties that are common to any user model.

Doc={_id:new ObjectId ("4a5b1476238d3b4dd5000001"), email: "[email protected]", first_name: "Kyle", last_name: "Banker" , Hashed_password: "bd1cfa194c3a603e7186780824b04419", address:[{Name: "Home", Street: "588 5th Street", City: "Brooklyn ", State:" NY ", zip:10010},{Name: ' Work ', street: ' 1 e.23rd Street ', City: ' New York ', State: ' NY ', zip:10010}],payme nt_methods:[{Name: "VISA", last_four:2127, crypted: "43f6baldfda6b8106dc7", Expiration_date:new date (2014,4)}]}

2.3 Reviews Info

General products will have comment information. In general, a product has multiple comments, and the relationship is also encoded using the object ID application product_id.

doc={_id:new ObjectId ("4c4b1476238d3b4dd5000041"), Product_id:new ObjectId ("59884b76b53fab2a8024b6ad"), date:new Date (2010,5,7), title: "Amazing", Text: "Has a squeaky wheel,but still a darn good wheel barrow", Rating:4, User_id:new obje CtId ("4a5b1476238d3b4dd5000001"), user_name: "Dgreenthumb", Helpful_votes:3, voter_ids:[{new ObjectId (" 59884b76b53fab2a8024b600 ")}, {new ObjectId (" 59884b76b53fab2a8024b601 ")}, {new ObjectId (" 59884b76b53fab2a8024b602 ") }}

In the evaluation information above, because MongoDB does not support junction queries, redundancy stores user_name and a voter_ids array to store the users who vote on the comment. It removes duplicate votes and also gives us the ability to query all comments that a user has voted for.

At this point, we have covered the e-commerce data model, explained the specific modeling methods, and because MongoDB does not support the limitations of the connection query to the regularization solution, so as to find a most suitable for the application of the schema.

This article from "Techfuture" blog, declined reprint!

MongoDB Combat-Document-oriented data (find the most appropriate way to model your data)