What principle to use for storing data in MongoDB?

Question

MongoDB

A web service is being written (say, for a book catalog). Node.js + MongoDB are used. There was a question on storage of the data in base. What is the best approach to use? There are two main data types - user, book. The presence of additional types depends on the variant.
There are 2 options:
1) Do not use additional data types, that is, store all data about the work in a separate document of the "Works" collection (that is, reviews about it, author's name, category, etc.)
2) Use additional data types, that is, create associated collections with "Works" - "Reviews", "Categories of works", "Authors".
In the future, it will be necessary to store and edit huge amounts of information, and therefore it is interesting
Can you recommend any other approach? Suppose we refuse to use a schemaless database? All data must be clearly structured.

Answer 1

I recommend reading "50 Tips and Tricks for MongoDB" . Not a lot of text, but a lot of information. Here in the answers they got a little confused - what you have under the 1st point is a denormalized collection. The advantages are that in one request you have all the information on the object, but the disadvantages, respectively, are that it is difficult to apply edits. And the 2nd point, this is already normalized - and here everything is vice versa. But the main thing is to correctly balance between them, and not choose one of the sides. The structure very much depends not only on the data structure, but also on how we use this data (what selections we will make) and how important their relevance is. A couple of tips from different angles:
- if you go the first way - you can also store all subentities in separate collections. When you change a subentity, you change it in your collection, and don't be afraid to write normalization scripts that will update the main collection by cron.
- and if according to the second, then store not only `_id` subentities, but also a part of the object, which will always be needed to minimize requests.

Answer 2

It depends on the use, for example, if reviews are displayed on the page of the book and nothing else happens to them, then it is convenient to make them nested, + saving on requests, one request will get the book and reviews.
But the authors are better (possible) in a separate collection, tk. their data will change (name, photo, description, tags?), although if these changes are very rare or not at all, then they can be nested, while there will be more disk consumption, but savings on queries.

Answer 3

We need reasonable normalization here. As mentioned above, one entity - one document. But do not forget at the same time that excessive duplication of information (like the author) is not good. For, if something changes with the author, it will be necessary to shovel all the documents with this author.
The beauty of schemaless is the absence of a schema. That is, you can give different attributes to different entities, while keeping everything in one collection and indexing all these attributes. If the structure is supposed to be more regular, if the scheme is present, then it is worth contacting the storages with the scheme.

Answer 4

A relational data storage system suggests itself.
What were you guided by when choosing mongo for such a task?

Answer 5

In the future, it will be necessary to store and edit huge amounts of information

In terms of volume, you will probably have pictures (posters) for books, but they can take up most of the storage (+ most of the expense), I worked with one book site - there are several pictures for each book with reviews (~ 4kb) ( ~120kb), i.e. ~97% (from books) are pictures.

Answer 6

Books still fit well into the relational model, why is mongo there?