If the user information will be updated, the user_id must be stored and then obtained separately (usually it has been obtained when the user logs in and cooperates with redis for storage calls). Also, do not ignore the storage read speed of mongodb. This is mongodb The advantage lies in. Personally speaking, all my projects store users separately and then call them through user id. for reference only.
Of course you save the ID. Logically speaking, if the user logs out/is deleted/reported/has illegal content, but what you save is the actual data, how do you modify it then?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
If the user information will be updated, the user_id must be stored and then obtained separately (usually it has been obtained when the user logs in and cooperates with redis for storage calls). Also, do not ignore the storage read speed of mongodb. This is mongodb The advantage lies in. Personally speaking, all my projects store users separately and then call them through user id. for reference only.
It is indeed difficult to measure with a standard
If you want to combine multiple tables, it will be a bit troublesome because it is an asynchronous operation.
If you change relatively mundane data, use ID to associate it
Most of the time, user_id is stored, which is easier to manage
Of course you save the ID. Logically speaking, if the user logs out/is deleted/reported/has illegal content, but what you save is the actual data, how do you modify it then?