In fact, the design philosophy on the official website is quite good (http://www.mongodb.org/display/DOCS/S...)
The biggest difference between MongoDB and traditional SQL schema design is which method is better to express the model relationship (in MongoDB, you can use either Link or Embedded)
A brief summary:
FirstClass (such as "User") should use an independent Collection
"entry type" should be embedded
If there is an inclusion relationship between two models, use embedded
Many-to-many relationship, use link (similar to foreign key in SQL)
If a model may store very few objects, then use an independent collection, which will help the mongodb server do caching
The embedded method is not conducive to complex associations and complex queries
The embedded method has great performance advantages. If you have "performance" requirements, you can consider using embed
I am still used to treating mongodb as an ordinary DB, treating collections as tables, and the data structure in each collection remains consistent.
I don’t know if this is reasonable, but at least it makes my thinking clearer.
NoSQL has a unique design philosophy, and it is recommended not to be influenced by RDB thinking.
Also recommend an article to read: MongoDB record mapping schema extremely free Java Entity
In fact, the design philosophy on the official website is quite good (http://www.mongodb.org/display/DOCS/S...)
The biggest difference between MongoDB and traditional SQL schema design is which method is better to express the model relationship (in MongoDB, you can use either Link or Embedded)
A brief summary:
I am still used to treating mongodb as an ordinary DB, treating collections as tables, and the data structure in each collection remains consistent.
I don’t know if this is reasonable, but at least it makes my thinking clearer.
NoSQL has a unique design philosophy, and it is recommended not to be influenced by RDB thinking.
Also recommend an article to read:
MongoDB record mapping schema extremely free Java Entity