MONGODB data structure and comparison with MySQL

MySQL has always been the most cost-effective relational database model

MongoDB brings a NoSQL experience outside the relational database.

Let's look at a simple example of how we will create a data structure for MySQL (or any relational database) and MongoDB.

MySQL Design

Let's assume a design table:

People people information table contains ID and name fields

Passports Passport table, which mainly contains the foreign key ID of the corresponding people table, the country of ownership, and passport validity

Mysql> Select *  frompeople;+----+------------+|Id|Name|+----+------------+|  1 |Joker||  2 |John||  3 |Michael||  4 |Cinderella|+----+------------+Mysql> Select *  frompassports;+----+-----------+---------+-------------+|Id|people_id|Country|Valid_until|+----+-----------+---------+-------------+|  4 |         1 |FR| 2020- on- on  ||  5 |         2 |US| 2020- on- on  ||  6 |         3 |RU| 2020- on- on  |+----+-----------+---------+-------------+

You can then proceed to the following basic functions:

How many people are there?

SELECT Count (* from people

Check out the passport validity of Joker

SELECT  from Join  on = WHERE = ' Joker '

How many people have passports in the wood?

SELECT  from  Left JOIN  on = WHERE  is NULL

the design of MongoDB

The next step is to design in MongoDB.

The use of three-paradigm in relational database, although normative, but not high, because the correlation is not high, there is no need to use the three-paradigm to design.

One is the "straight-tube" design, and the understanding of relational database is not very different

{"_id": ObjectId ("51F7BE1CD6189A56C399D3BF"), "name": "Joker", "Country": "FR", "Valid_until": Isodat E ("2019- A-31t23:xx: 00Z ")} {"_id": ObjectId ("51f7be3fd6189a56c399d3c0"), "name": "John", "Country": "US", "Valid_until": Isodate ("
    2019- A-31t23:xx: 00Z ")} {"_id": ObjectId ("51f7be4dd6189a56c399d3c1"), "name": "Michael", "Country": "RU", "Valid_until": Isodate ( "2019- A-31t23:xx: 00Z ")} {"_id": ObjectId ("51f7be5cd6189a56c399d3c2"), "name": "Cinderella"}

MongoDB no fixed structure, each table each piece of data can have a different structure, which is both a good and a disadvantage, the disadvantage is that you have to understand the structure of the table MongoDB, which in fact to the maintenance personnel to bring a certain discomfort and trouble.

2, the following is the design method of MongoDB features, both: The people information and passport information soft together

{"_id": ObjectId ("51f7c0048ded44d5ebb83774"), "name": "Joker", "Passport": {"Country": "FR", "Valid_until": Isodate ("2019- A-31t23:xx: 00Z ")}} {"_id": ObjectId ("51f7c70e8ded44d5ebb83775"), "name": "John", "Passport": {"Country": "US", " Valid_until ": Isodate ("2019- A-31t23:xx: 00Z ")}}        {"_id": ObjectId ("51f7c71b8ded44d5ebb83776"), "name": "Michael", "Passport": {"Country": "RU", "Valid_until": Isodate ("2019- A-31t23:xx: 00Z ")}} {"_id": ObjectId ("51f7c7258ded44d5ebb83777"), "name": "Cinderella"}

3, the same, the above structure can also be field in reverse design, if there is no "valid_until" field represents no passport

{"_id": ObjectId ("51f7c7e58ded44d5ebb8377b"), "Country": "FR", "Valid_until": Isodate ("2019- A-31t23:xx: 00Z ")," person ": {" name ":" Joker "}}{" _id ": ObjectId (" 51f7c7ec8ded44d5ebb8377c ")," country ": "US", "Valid_until": Isodate ("2019- A-31t23:xx: 00Z ")," person ": {" name ":" John "}}{" _id ": ObjectId (" 51f7c7fa8ded44d5ebb8377d ")," country ": "RU", "Valid_until": Isodate ("2019- A-31t23:xx: 00Z ")," person ": {" name ":" Michael "}}{" _id ": ObjectId (" 51f7c8058ded44d5ebb8377e "), ' person ' : {"name": "Cinderella"}}

Sum

One of the fundamental differences between MySQL and MongoDB:

1, the use of MongoDB, architecture design becomes extremely important, once there is a link between the design of the problem, will bring catastrophic maintenance and rework consequences, not to mention optimization. But the same problem is forcing us to make a good structure to develop good habits.

2, which way is better? Of course, there is no definite answer. Different environments use different ways, like the above example to fully use MongoDB more efficient, such as single-table data up to 10 million, MySQL association query is very pit dad. For multi-business logic Complex Association design, MongoDB is not incompetent, the key we can not guarantee that our software needs like a foreigner will not always change or overturn rewrite, so with MySQL easier to maintain

MONGODB data structure and comparison with MySQL