How to design relationships in MongoDB?

Question

JavaScript

I decided to transfer the database of the card game to MongoDB, but due to working with relational databases, I don’t quite understand how to do it correctly (in terms of the least load).
There are many cards that players can create and add to their collection, all cards, among other things, are combined into groups (clans).
Given:

• The cards document - where is the list of all cards with their id
  
• Document players - where, among other things, a list of cards available to the player
  
• The clans document - where is the list of cards of a certain clan
  

In a relational database, I would simply store both for players and for clans a list of id's by which I made a selection from cards .
In a document-oriented database, a more correct way (as far as I understand) would be to store the entire map in players and clans , which would not have to make unnecessary requests.
This option suits me, but it turns out that if the map is updated in cards , then I have to go through all the documents to bring copies of this map up to date? Wouldn't it be even more expensive than constantly fetching maps from one document by id ?
Help to understand, please.

Answer 1

I decided to transfer the card game database to MongoDB

What for? If you have at least a 10% chance that there will be relationships / connections between records, then monga is not suitable for you.
Mongu should be used exclusively for storing denormalized data. That is, usually everything is stored in a relational database and then the data is aggregated in a denormalized form in order to speed up the selections. In this case, we can have one database in a normalized form (mysq/postgres/etc) and many mongo instances from which data is only read, but nothing is written (except for aggregations initiated by changing data in a relational database.
And then this is only needed if you have problems with the relational database (for example, you have to do a lot of joins in case of complex selections) If you have one or two joins, then place the indexes and don't worry.
ps says a person who knows firsthand how bad life is if monga was chosen as the main data store on the project if there are connections between them.

Answer 2

Help to understand, please.

You have a relational data structure, for this you should use an RDBMS.
You are tormented with monga.

Answer 3

Here, apparently, it is worth looking at the architecture of the game server in general. For example, it may be beneficial to have this collection of maps loaded at startup and always stored in the server's memory, only synchronized with Mongo. Then you will have a list of card ids in the documents for the player, and then in the application you will associate it with the actual list of cards with parameters. For most cases this will work. then you need to look at the number of cards, users, operations with them, scaling - but this will already be the level of thousands of players online, which will be just a super-cool take-off for the game.

Answer 4

well, it's stupid to stuff relational data into a document-oriented mongu