Currently, data from the gamemode is stored via an external application called SSC or "ScavengeSurviveCore". That project can be found here
There are a number of reasons for this:
Language
Pawn isn't the nicest language. In my opinion, it's best to avoid using it for anything other than interacting directly with the SA:MP API for scripting gameplay mechanics.
Building queries, serialising data, working with trees, arrays, objects and hashmaps isn't a nice experience at all. It's messy, requires lots of overhead for conversions and it isn't type safe, only tag safe.
Building the storage layer in a language such as Go allows for all of those problems to be solved.
Separation
Separating the storage layer to another application allows it to be individually unit-tested. It also provides a boundary via an API which can be easily documented automatically using the data inside the application.
This also means the database internals can be tweaked and updated without bringing down the main server. As long as the API contracts are intact, all services communicating with the database remain online. These internals may be things such as optimisations, changes to the internal data structure or additional endpoints and features.
MongoDB
Another reason for choosing this path was being able to use any database, not just MySQL - and not just relational databases. Because this project will evolve fast, with new pieces of data being added to players with each new feature, keeping track of a schema and making sure it's updated can be a hassle.
Another reason for MongoDB is the ability to use tree structures for nesting data such as complex objects and arrays. This can be much simpler than dealing with one-to-many relationship tables with the relational model - depending on the use-cases of course. MongoDB does have a powerful aggregation toolset for performing the same operations as JOINs.
Assuming MySQL plugin usage: In development this would involve spinning up a new database with the new schema each time, which isn't much of a problem but in production, performing an alter table requires bringing down the game server in order to perform the update on the live data, running tests to ensure it's fine then bringing up the game server again.
With the separation model, if MongoDB doesn't work out, it can easily be switched out with no necessary changes to Pawn code. The database could be swapped out for Postgres or MySQL before launch if necessary.
External Access
(By external I mean other applications within the same network, not public access)
In future, other web services may want to interact with this data (a statistics page or a user control panel for example). The web uses JSON already and since the SSC API provides data as JSON, building a UCP or statistics page or any kind of frontend would be extremely simple given the data is readily available to consume and display. Using a database without an API would require writing a backend that directly talks to the database, queries the data then processes it in order to turn it into JSON data for being used on the frontend.
Summary
So this is why the service model + MongoDB was chosen for this project. Yes it's new, yes it may be confusing at first. However, I believe with good documentation and well designed boundaries and APIs, this model is far superior to the traditional SA:MP approach of baking database interactions into Pawn code.
Hopefully this covers everything, ask questions below and I'll answer anything that isn't already here.
Poke holes in this concept and criticise it as much as you can!
Currently, data from the gamemode is stored via an external application called SSC or "ScavengeSurviveCore". That project can be found here
There are a number of reasons for this:
Language
Pawn isn't the nicest language. In my opinion, it's best to avoid using it for anything other than interacting directly with the SA:MP API for scripting gameplay mechanics.
Building queries, serialising data, working with trees, arrays, objects and hashmaps isn't a nice experience at all. It's messy, requires lots of overhead for conversions and it isn't type safe, only tag safe.
Building the storage layer in a language such as Go allows for all of those problems to be solved.
Separation
Separating the storage layer to another application allows it to be individually unit-tested. It also provides a boundary via an API which can be easily documented automatically using the data inside the application.
This also means the database internals can be tweaked and updated without bringing down the main server. As long as the API contracts are intact, all services communicating with the database remain online. These internals may be things such as optimisations, changes to the internal data structure or additional endpoints and features.
MongoDB
Another reason for choosing this path was being able to use any database, not just MySQL - and not just relational databases. Because this project will evolve fast, with new pieces of data being added to players with each new feature, keeping track of a schema and making sure it's updated can be a hassle.
Another reason for MongoDB is the ability to use tree structures for nesting data such as complex objects and arrays. This can be much simpler than dealing with one-to-many relationship tables with the relational model - depending on the use-cases of course. MongoDB does have a powerful aggregation toolset for performing the same operations as JOINs.
Assuming MySQL plugin usage: In development this would involve spinning up a new database with the new schema each time, which isn't much of a problem but in production, performing an alter table requires bringing down the game server in order to perform the update on the live data, running tests to ensure it's fine then bringing up the game server again.
With the separation model, if MongoDB doesn't work out, it can easily be switched out with no necessary changes to Pawn code. The database could be swapped out for Postgres or MySQL before launch if necessary.
External Access
(By external I mean other applications within the same network, not public access)
In future, other web services may want to interact with this data (a statistics page or a user control panel for example). The web uses JSON already and since the SSC API provides data as JSON, building a UCP or statistics page or any kind of frontend would be extremely simple given the data is readily available to consume and display. Using a database without an API would require writing a backend that directly talks to the database, queries the data then processes it in order to turn it into JSON data for being used on the frontend.
Summary
So this is why the service model + MongoDB was chosen for this project. Yes it's new, yes it may be confusing at first. However, I believe with good documentation and well designed boundaries and APIs, this model is far superior to the traditional SA:MP approach of baking database interactions into Pawn code.
Hopefully this covers everything, ask questions below and I'll answer anything that isn't already here.
Poke holes in this concept and criticise it as much as you can!