Please share the general NoSql Data Modeling best practices you have been following for your games.
I am specifically looking for following two aspects of GameSparks NoSql capabilities:
1. Do you recommend more relational approach of data modeling where in each document carries just identifiers or unique keys which can be mapped to other documents containing the relevant information or large documents carrying all the related information. Obviously in the former case multiple operations have to be executed to collect and push a single player information to client. In later case a single operation might be enough to fetch all relevant data for a player action but this required inserting and updating multiple copies of same data across documents. So which one is preferred for GameSparks MongoDB NoSql? Have any of you observed any advantages or disadvantages with your own implementations?
2. Do we have to take care of short form naming of various keys to keep the overall data size minimal? Or does MongoDB/GameSparks manages this internally. I mean does it really help to use "p" instead of "power" as key name?
Kindly share any other general or GameSparks specific NoSql best practices.
Thank you.
Navin
Best Answer
C
Customer Support
said
almost 6 years ago
Hi Navin,
We have some documentation on the common tasks involving database access and cloud storage located here. Have a read through those and if you have any specific questions afterwards just let us know.
Regards,
Liam
1 Comment
Customer Support
said
almost 6 years ago
Answer
Hi Navin,
We have some documentation on the common tasks involving database access and cloud storage located here. Have a read through those and if you have any specific questions afterwards just let us know.
Navin Kasa
Hi All,
Please share the general NoSql Data Modeling best practices you have been following for your games.
I am specifically looking for following two aspects of GameSparks NoSql capabilities:
1. Do you recommend more relational approach of data modeling where in each document carries just identifiers or unique keys which can be mapped to other documents containing the relevant information or large documents carrying all the related information. Obviously in the former case multiple operations have to be executed to collect and push a single player information to client. In later case a single operation might be enough to fetch all relevant data for a player action but this required inserting and updating multiple copies of same data across documents. So which one is preferred for GameSparks MongoDB NoSql? Have any of you observed any advantages or disadvantages with your own implementations?
2. Do we have to take care of short form naming of various keys to keep the overall data size minimal? Or does MongoDB/GameSparks manages this internally. I mean does it really help to use "p" instead of "power" as key name?
Kindly share any other general or GameSparks specific NoSql best practices.
Thank you.
Navin
Hi Navin,
We have some documentation on the common tasks involving database access and cloud storage located here. Have a read through those and if you have any specific questions afterwards just let us know.
Regards,
Liam
Customer Support
Hi Navin,
We have some documentation on the common tasks involving database access and cloud storage located here. Have a read through those and if you have any specific questions afterwards just let us know.
Regards,
Liam
-
Documentation Notes
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2487 topics