Comparison of MongoDB pattern design between relational database and Key-value-type database

MongoDb compared to the traditional SQL relational database, the biggest difference lies in their schema design (schema) differences, it is because this level of differences derived from other aspects of the difference.

we can simply think that the relational databaseconsists of three hierarchical concepts of database, table and record, while in constructing a relational database, the emphases and difficulties are divided and organized in the database table. In general, in order to balance the contradiction between increasing access efficiency and reducing data redundancy, the design of database tables will try to satisfy the so-called third paradigm. In contrast, MongoDB can be thought of as a database, a collection (collection), a Document object (document-oriented, BSON) three levels. The collection in MongoDB correspond to the tables in the relational database. Of course, do not expect collection to satisfy the so-called third paradigm, because they are not in the same conceptual discussion at all. Similar to a table consists of multiple records, the collection also contains several document objects, although it is generally said that a document object within the same collection has the same format definition, but this is not necessary, that is, MongoDB's data schema is free (schema-free, mode free, modeless).

as an example, suppose we need to design a small database to store "student, address, subject, score" information, then the relational database is designed in 1, and the Key-value-type database is designed to be 2.

Figure 1, relational database design

Figure 2, Key-value type database design (directly borrowed MongoDB official map)

Comparing figures 1 and 2, there are 4 tables in the relational database design, and there are only two collections in the Key-value database design. If the set corresponds to table one by one, then Figure 2 should also have 4 sets to the right, why can this should be the set of address and scores directly into the set students? The reason is that in the Key-value type database, the data schema is free.

In the case of scores, it is a single table in a relational database design because student and score are a one-to-many relationship, and if you combine score into a student table, you must reserve the most possible fields, which can be wasteful and will be difficult to expand when you add a new course later , so the score table is generally separated out. And for Key-value type database is different, its scores field is a Bson, the Bson can have only one for_course, can also have two, three, any for_course, Its inherent pattern-free nature makes it possible to include score without having to build another score collection.

For a one-to-one relationship with student Address Table can also be directly into the student, without worrying about the extensibility of the address, when you need to add a province field to address, directly in the data inserted with this value.

Of course, for course tables with many-to-many relationships with student, to reduce data redundancy, course can be built as a collection, similar to the relational database design.

In contrast to relational databases, there are several advantages to joining data together in a Key-value database: First, there is no significant overhead associated with table joins (although there is currently no join concept in MongoDB); The data that comes together is more easily stored on disk, so the data reads/writes faster. In addition, there is no need to worry about extensibility issues, the Key-value-type database's own characteristics make it easy to change the fields and additions.

Comparison of MongoDB pattern design between relational database and Key-value-type database