mysql: There are 5 fields in a table. Your program has been written, and then you need to add two fields here, so you first go to the database to modify the table structure, add fields, and then return to the program and modify the sql code.
mongodb: An object has 5 attributes. Your program has been written. Then you need to add two attributes (fields) here. You can add them directly in the program and it will be OK.
In a relational database, a record is a row, a field is a column, and the data is at the intersection of rows and columns. Multiple rows and columns must follow the same two-dimensional structure.
Non-relational database, attributes only belong to objects. Objects are independent from each other.
For long-term business, use the combination of mysql+memcache, and for statistical log business or temporary transactions on the PM’s forehead, use the combination of mongodb+redis. The advantage of mongodb is flexibility, the disadvantage is also flexibility, and its stability is not as good as mysql
Compared with traditional relational databases, MongoDB is one of the representatives of non-relational databases. To know when to use MongoDB, you should first know what features it has, what it can and cannot do, and then decide whether to use it based on the specific situation. It is recommended to read the introductory part of the official documentation first, which lists the most critical features of MongoDB, and almost all other functions revolve around these features. These features are often the key factors in deciding whether to adopt MongoDB. Here is an article that briefly and roughly introduces how to choose. However, with the development of technology, the boundaries between the so-called "relational" and "non-relational" have become increasingly blurred. On the one hand, traditional RDBMS such as Postgre and MySQL have begun to support non-relational models such as JSON. On the other hand, MongoDB has also begun to JOIN is supported and even transactions will be supported in the future. Now that the boundaries have become blurred, it cannot be generalized when which technology should be used. The comparison result is often that both this and that can be used. But you can indeed compare what you will gain and lose if you use a certain technology in your project, and then weigh whether the gain can make up for the loss, and ultimately decide whether to adopt this technology.
It is best to use mongodb when the data structure is not certain. For example, in your sql database, you must first define the types, names, lengths of all fields, etc. This lacks flexibility. When mongodb does not exist in a certain field, it will He didn't.
For example, suppose our server wants to save system events in the database. When a certain user does something, sometimes you need to record the original body content of the post he sent for query, and sometimes you don't. Then when you don't need to record the post content, if you define string in SQL If the length is 1000, this space is wasted, but mongodb will not. And when fetching this record, the SQL database will return the structure you defined, even if one of the fields is empty, and mongodb does not include the empty field when saving, and it will not be fetched when it is fetched. have.
Also, mongodb supports various json structures very well. Of course, this should not be the main purpose of using mongodb.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Give me an example:
mysql: There are 5 fields in a table. Your program has been written, and then you need to add two fields here, so you first go to the database to modify the table structure, add fields, and then return to the program and modify the sql code.
mongodb: An object has 5 attributes. Your program has been written. Then you need to add two attributes (fields) here. You can add them directly in the program and it will be OK.
In a relational database, a record is a row, a field is a column, and the data is at the intersection of rows and columns. Multiple rows and columns must follow the same two-dimensional structure.
Non-relational database, attributes only belong to objects. Objects are independent from each other.
For long-term business, use the combination of mysql+memcache, and for statistical log business or temporary transactions on the PM’s forehead, use the combination of mongodb+redis.
The advantage of mongodb is flexibility, the disadvantage is also flexibility, and its stability is not as good as mysql
Compared with traditional relational databases, MongoDB is one of the representatives of non-relational databases. To know when to use MongoDB, you should first know what features it has, what it can and cannot do, and then decide whether to use it based on the specific situation. It is recommended to read the introductory part of the official documentation first, which lists the most critical features of MongoDB, and almost all other functions revolve around these features. These features are often the key factors in deciding whether to adopt MongoDB.
Here is an article that briefly and roughly introduces how to choose.
However, with the development of technology, the boundaries between the so-called "relational" and "non-relational" have become increasingly blurred. On the one hand, traditional RDBMS such as Postgre and MySQL have begun to support non-relational models such as JSON. On the other hand, MongoDB has also begun to JOIN is supported and even transactions will be supported in the future. Now that the boundaries have become blurred, it cannot be generalized when which technology should be used. The comparison result is often that both this and that can be used. But you can indeed compare what you will gain and lose if you use a certain technology in your project, and then weigh whether the gain can make up for the loss, and ultimately decide whether to adopt this technology.
It is best to use mongodb when the data structure is not certain. For example, in your sql database, you must first define the types, names, lengths of all fields, etc. This lacks flexibility. When mongodb does not exist in a certain field, it will He didn't.
For example, suppose our server wants to save system events in the database. When a certain user does something, sometimes you need to record the original body content of the post he sent for query, and sometimes you don't. Then when you don't need to record the post content, if you define string in SQL If the length is 1000, this space is wasted, but mongodb will not. And when fetching this record, the SQL database will return the structure you defined, even if one of the fields is empty, and mongodb does not include the empty field when saving, and it will not be fetched when it is fetched. have.
Also, mongodb supports various json structures very well. Of course, this should not be the main purpose of using mongodb.