Question about settings storage

[Zeggy]

I am having some doubt about how to store my data in a game...
Before now, I have always stored all settings in a 'settings' table in a database, except for db info (duh!).
And such things as unit info and building info, has all been in tables as well.

But now I am wondering... would it be better to have it all in a php page in a multidimensional array?

Eg.:

Code: [Select]

<?php
//settings.php

//Riot Center
$config['race'][0]['building'][0]['name'] = "Riot Center";
?>
There are both advantages and disadvantages to this.
One advantage is that there's no need to store relational data, such as which ID is its own ID, and which one is referring to another row in another table.

A big disadvantage is that the data is not as easy to work with (for me). I don't use multidimensional arrays much... never needed to use them.
Another disadvantage is that it is harder to show ordered/rearranged data.
With mysql we could just use 'order by `name`' or something similar. I'm sure there's a function in PHP to sort arrays, but yeah... I've never worked with it before.
It's also more difficult to insert data. You'd have to do it by hand, and type out the whole array['key']['another key']=value, etc.

I'm only considering this option because some bigger games use the latter option of putting it all in a text file. (Such as kings of chaos.)

If it's more efficient to use a database, then I'm just gonna use it... Won't bother making it harder for myself >>

[dvd871]

The advantage Zeggy is that you don't use as many SQL calls to get simple data.

I try to keep my arrays simple for me to remember so something like you mentioned: $config['race'][0]['building'][0]['name'] = "Riot Center";

I would use something like:
$config['race1']['building_name'] = "Riot Center";

And say that you have 5 races, then you could put each races config in a different file and just include it where needed.

If you were to use the database to store config data you must read the entire table every time to get what you need, even if it is just one value.

[Zeggy]

Oh yes... Put the different sections in different pages rather than making the arrays even more complicated...
That's nice and simple

I suppose any sql query to a table to perform different tasks (such as a random row, or row count) could be mimic'ed in PHP with array functions?

[dvd871]

I don't see why not.  To get random elements from an array just use the array_rand() function.

Of course I just had a thought.  If you use ADoDB you could take advantage of query caching and cache your settings table.  Since the settings wouldn't change that might be an option.  Once cached you read the data from the query cache instead of reading the entire table each time.  Problem is I'm not 100% sure that is possible.  I don't know how long the cached queries are maintained before the are purged.

Another option would be to maintain your settings using sessions.  Man I'm full of ideas tonight, lol!  Query once and store the settings in the $_SESSION array, then if you needed a settings value you could just do $var = $_SESSION['setting'];  If you have a busy site with lots of users though I think I would opt for the config.php file method as its simply less overhead.

[Zeggy]

Thanks for the ideas
I think I'll opt for the Session method, or just use flat files.
Or maybe if I can figure out how the query caching works, I'll give it a try

[codestryke]

Wow lot of misconceptions about how databases work!

First if you have a settings table and have two fields in it called "setting" and "value" and you place a unique index on the settings field a query such as:

SELECT `value` FROM settings WHERE `setting` = 'basecost'

The database WILL NOT read the entire table into memory, nor will it load the table into memory. It will look to the index, find what it needs and go directly to that entry in the table. Make a sample table, populate it with some data then perform the above query. Using phpMyAdmin click the Explain SQL link, this will show you something like:
 id      select_type      table      type      possible_keys      key      key_len      ref      rows      Extra
1     SIMPLE     config     const     PRIMARY     PRIMARY     50     const     1     

As you see it shows a 1 for the number of rows it had to analyze to get your data, not the entire table.

--------------------------------------------------------

Query caching is turned on by default in the laster versions of mySQL. So it really depends on what version you are running or what options you or your host made when installing mySQL.

When turned on and installed you tell mySQL how much memory should be allocated to store the cache and then mySQL manages the cache itself based on number of the queries run in a given amount of time. You can, of course, tweak these settings as well. mySQL also stores a number of different stats on the cache that will allow you to tweak it accordingly.Finally you don't need to use ADODB to use the query cache, if your mySQL install has it you can use it no matter how you access the database.

--------------------------------------------------------

Unless you plan to encrypt your session data then putting that sort of data in the session is probably the worst possible idea ever, sorry. Session data is stored both on the server and on the client "NEVER TRUST THE CLIENT".. With Firefox and the Web Developer plug-in I could easily change my session data and basically cause havok on your game, take over different player accounts and if you have admin functions via the game then I could also do that as well.

--------------------------------------------------------

If you have settings information that doesn't change and is pretty static then, yes, a include file would be the best possilbe solution. If it's dynamic then the database is your best bet. You can go with a flat file but are you read to code lock and lock wait functions for that text file (assuming it's dynamic data)?

I use both methods, an  include file for data that is static though the course of a game round and a settings table for data that gets updated though out the round. Most of the data that gets "hit" a lot I try to offload it to the include file but if it's dynamic in nature then mySQL, a nice optimized database and a good chuck of memory allocated to the query cache performs quite nicely (5million+ page views a day, running about 20-30 queries a second)


Hope this sheads some light on how databases really work and gives you a better idea of what direction to take.

[Mgccl]

arrays store everything... man... what are Object for..?
anyway, if there are only a little setting and will be used in almost EVERY single place... why not use a PHP script for it. Reduces mysql connections...

[Zeggy]

Well, what the array stores depends on your query.
Like codestryke said, if you are selecting a single row, then your array will only contain that single row's information.

Okay, so scratch the sessions idea.
I've figured out how to work with adodb cache, but I never knew mysql had its own built-in cache. How does it work?

What's the advantage of using adodb cache then?

I may go for the static file include then...




EDIT:
err...
btw, I thought you couldn't edit sessions...
All session data is stored on the server, and the only thing stored locally is the session ID, which refers to the data on the server. That's the difference from cookies. Cookies you can edit, but sessions you can't because cookies are stored locally. But I might be wrong.

[Mgccl]

session... you mean what? session_id?
session are stored on the server... so SERVER can edit it....
which means if you give some interface... a CLIENT can edit it tooooo

[Zeggy]

Yeah, we were talking about a player editing his own session data. Only the server can edit session data right?
The user can only edit his local reference to the session id.

[Mgccl]

yeah.... client can't change the session data. but.. do you want them to change? because I don't get it

[Zeggy]

No, I don't want them to change their session data
codestryke was just saying that using sessions to store game settings isn't so smart because they can edit it.
Well, I won't be using sessions for game settings any more (well, I never did anyways XD)

[codestryke]

Session data can be stored either on the client via a cookie and/or on the server based on what browser you use. Often times things get confused and it throws the session data to the cookie, once they have the layout of how you are storing your data then they can mess with it

Also there is a way to hijack sessions very easily. A badly written BBCode parser that allows the {img} command can be configured in such a way as to pass the session key to them via javascript. They then plug it into the browser and wha-la they have control of that session / ie player account...

The reason I know all this is because I've been hacked by each of the above methods! Once your game reaches a certain size or targets a certain audience they will start to try and hack your game. For them finding exploits in your game and manipulating them is the game. Right now, in the states, school is in session so it's not to bad. It's 100x worse in the summer when they have no school and have nothing better to do then to pick apart every aspect of your game on page and function at a time

[Zeggy]

lol, okay
my site's been hacked before, and it's not a pretty thing  T_T