How to properly store an article's rating in an unstructured database?

Question

MongoDB

I have only recently started using these solutions. I wanted to for a long time, but there was no project where I could play with them. Well, now there is.
I have such a problem. I don't want to port my experience from RDBM to NoSQL. I do not want to try to reproduce on Mongo what I did on MySQL. And here is such a question as an example of a concept.
There is an article and there are its ratings. An article can have a maximum of 1000 ratings, and on Wednesday 100. Rating is

{
   "value": 20,
   "user": new MongoId(),
   "ip": "120.120.120.120",
   "time": 123235656,
}

I see several ways to save.
1. RDBM style is when I have 2 collections. In one, I save the articles in the other ratings and in the rating, a link to article
2. This is also in different collections, but a little differently. I think this method is possible only in NoSQL databases. It can be played on RDBM but no one does. This is when the link to the rating is written not in the rating but in the article.

{
   "name" : "Title",
   "ratings: [
      Object("ksdj7sdf7s8sd76gsdfd09g8h9f8gh"),
      Object("ls78f0gh9gf0vbfx7x8v7c9v8b78c")
   ]
}

3. Well, the 3rd way is if the millet completely saves the rating in the article document. There is only one collection.
What approach would be the most correct?

Answer 1

I don’t understand these nosql databases: the rating refers to the article, here is a typical relational model.
Adepts of these bases will most likely advise option three, as without mixing flies and cutlets)

Answer 2

In my opinion, with any base it is desirable to adhere to the rule: keep separately what changes often and what rarely changes. Especially if frequently changing data is not so scary to lose completely or partially.
From experience with noSQL, you don’t need to put everything in one collection, and even more so in one record, so you can put the whole site - such a huge array. It's like they finally gave you a big bag and put food, socks, and milk in it.
nosql helps a lot when there is some concept, but all the properties are not completely clear. Let's say ads. There are many rubrics and each rubric has its own parameters. NoSQL perfectly stores any set of parameters and can make a selection based on them (hello MySQL with serialized data).