The big principle is to design based on Access Pattern. Fortunately, we already have typical application scenarios.

1. The one-to-many relationship between team and player can be embedded or separated. It mainly depends on whether these two data are often used together. Examples of using them together: SegmentFault's questions and answers are also one-to-many, but are often displayed together. If not, you can separate it and add the player's name, _id, playing time and other basic information to the team. This kind of denormalization will require one more place to update when it needs to be updated. But since the update frequency of this information (such as transfers) is very low and it is read a lot, it is still worth it.

2. Statistics. If you recalculate a player's historical data, no matter what data inventory is used, you need to traverse the entire database, right? This is another trade-off before reading and writing. Obviously, data updates are much less than queries, so caching statistical data is meaningful. Furthermore, some statistics are constant, such as those for a team in a given season. When updating, it can be updated in real time, or some intermediate results can be cached, such as the average value from the total number and times to help calculations. Alternatively, updating once a day after each game is a possibility.

3. The data of each game is related to the game and the players, but is it often the same query as a certain one? If not, but only for statistical services, it is also good to put it in a separate collection.

4. Indices can help you find data faster, but they can’t help you reduce the resulting data set. After the data model is designed, it is natural to choose an index.