NoSQL rarely fully supports the Join function, so denormalized form is generally used to store the expanded relationship in NoSQL, so the relationship is no longer "many-to-one", but "one-to-many".
You can use collection types to store subdocuments, such as list or set in Redis, sub-document in MongoDB, etc.
For NoSQL, there is a simple principle, which is to put related things together, such as articles and comments. Note that if possible, try to put all attributes, including content, of articles and comments together, rather than just in the article. The id of the comment is stored in the record.
The advantage of this is obvious. You only need one read operation to obtain all the data related to this article. No matter how you segment the data, the article and its related things will not be separated into different physical machines. This can be extremely efficient. Greatly improve backend scalability.
Of course, such a design may not always be suitable for your application. For example, the relationship between articles and authors may not be completely denormailizeable, so you need to carefully consider the data presentation method and process to decide how to organize the data.
In short, NoSQL is not a panacea. While it provides higher flexibility, scalability and performance, it also simplifies the original black box database into a white box storage engine. You need to find out among the various factors yourself. The perfect balance, this job does require a lot of experience and a deep understanding of the business.
Of course, if the amount of data is small, this is not a problem.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
NoSQL rarely fully supports the Join function, so denormalized form is generally used to store the expanded relationship in NoSQL, so the relationship is no longer "many-to-one", but "one-to-many".
You can use collection types to store subdocuments, such as list or set in Redis, sub-document in MongoDB, etc.
For NoSQL, there is a simple principle, which is to put related things together, such as articles and comments. Note that if possible, try to put all attributes, including content, of articles and comments together, rather than just in the article. The id of the comment is stored in the record.
The advantage of this is obvious. You only need one read operation to obtain all the data related to this article. No matter how you segment the data, the article and its related things will not be separated into different physical machines. This can be extremely efficient. Greatly improve backend scalability.
Of course, such a design may not always be suitable for your application. For example, the relationship between articles and authors may not be completely denormailizeable, so you need to carefully consider the data presentation method and process to decide how to organize the data.
In short, NoSQL is not a panacea. While it provides higher flexibility, scalability and performance, it also simplifies the original black box database into a white box storage engine. You need to find out among the various factors yourself. The perfect balance, this job does require a lot of experience and a deep understanding of the business.
Of course, if the amount of data is small, this is not a problem.
Use list?
Isn’t it possible to use set? Put the id of comments in a post_id: set.