Does anyone know if NFO supports MongoDB, and if so what version are they using?
Currently I have a MySQL database on my web server that I use to manage player data, however most players have arrays associated with them (owned items, achievements, etc.) which don't play well with relational databases. I've done some research on using key-value pairs with MySQL, although it is very inefficient and would like to avoid it if I can, which brings us to MongoDB. MongoDB stores data in documents, which is exactly what I'm looking for, however according to the php documentation (http://php.net/manual/en/class.mongoclient.php), one of the main classes for it is deprecated, and requires a driver to work properly (http://php.net/manual/en/set.mongodb.php).
Any information would be greatly appreciated.
MongoDB questions
-
- New to forums
- Posts: 1
- https://www.youtube.com/channel/UC40BgXanDqOYoVCYFDSTfHA
- Joined: Sat Feb 06, 2016 6:29 am
Re: MongoDB questions
We don't currently offer MongoDB services.
SQL is designed for the use case of storing arrays -- in the form of tables -- combining many pieces of information about a subject. It seems like it is a better fit for your situation, and it would be more flexible than a KVS because you can tailor queries to perform operations on the data.
You could use separate tables that combine the playerid and some specific related attributes (as a handful of columns), or use a single table that combines all of them into one (all as separate columns), or use a table that generically combines playerid-key-value (where the key and value are things you define). In MySQL 5.7, you have the additional option of defining a table with a JSON column and dumping a whole JSON blob in there (allowing you to keep your arrays in whatever form you prefer).
SQL is designed for the use case of storing arrays -- in the form of tables -- combining many pieces of information about a subject. It seems like it is a better fit for your situation, and it would be more flexible than a KVS because you can tailor queries to perform operations on the data.
You could use separate tables that combine the playerid and some specific related attributes (as a handful of columns), or use a single table that combines all of them into one (all as separate columns), or use a table that generically combines playerid-key-value (where the key and value are things you define). In MySQL 5.7, you have the additional option of defining a table with a JSON column and dumping a whole JSON blob in there (allowing you to keep your arrays in whatever form you prefer).