What should be stored in the database for a Unity turn-based game?

Question

Unity

It is clear that all sorts of ratings, results, statistics, etc. the post-match should be stored in the database, but what about game objects, a map, various directories of object types?
I can not understand how to organize work with data, in what form to work with them? For example, there is a large hexagonal map for a turn-based strategy, should I fully describe the data model in the database? Each row in the session_map table is a cell with coordinates on the map and a session number, this table is associated, for example, with a cell reference (they may have different characteristics), etc. etc. and you just do an update for every change.
Or do I need to represent all this as objects, load it into memory and work with them in memory? Well then, if there are even several thousand players, the memory requirements will increase many times (?), So I found a similar oneunity3d.ru/distribution/viewtopic.php?f=105&t=35838 case.
What to store in the database, and what in the program memory? If it is still mandatory in the program memory, then what part should be stored in the database? Is an ORM necessary for this?

Answer 1

The server may freeze, or the electricity will go out, and you will lose all data from the RAM.
Therefore, you need to store in the database everything that is needed to restart the game from the same place.
At the same time, those things that are needed as often as possible should be kept in memory for acceleration.
If you're aiming for highload then check out in-memory and/or hybrid databases, you'll definitely need them.
For example, the same redis can keep a bunch of everything in memory, while in the background it also writes to disk.
The value of an ORM is only realized as the complexity and size of the code grows. On small projects, an extra ORM layer only interferes, on large projects it is very difficult to figure it out without it.
At the same time, even on large projects, there can be high-loaded modules in which the ORM is cut out for the sake of speeding up and saving resources.