views:

311

answers:

2

Hi, I am in dilemma situation, and do not know which one is better. Lets say I have 100++ (or more) games on my website. I want to store highscore for each game. Should i store all the highscore in 1 table or each game has its own table?

Compare:

1 table: 1 table contains a lot of rows(data). Every user play different game will submit score to this table. Dont know what will happen if many users submit at the same time. This table structure should be: gameID, name, score. So i just make 1 query to view what game's highscore in 1 php page.

If use multiple tables (each game has its own table), I would have many more tables but much lesser rows(data).

Which one is better in long run? How about the sql performance?

i am using php and mysql

+2  A: 

I would make a table for players, one for games and a many-to-many table for highscores with player_id, game_id and the highscore value.

Discussion

If you have 100.000 players and 500 games you can get to have a maximum of 50.000.000 entries. But they are numerical and very short. It will be a good idea NOT to serve this highscores using live queries but results from cached files. This is how almost everybody is doing. You update the cached lists of highscores each day. This way you do the writes live and the reads from cache and they don´t interfere.

Another suggestion it will be to reset the highscore table each month, or to keep older data separate based on access frequency. Facebook is doing something like this, as I´ve seen in a presentation of their lead developer.

Elzo Valugi
Thats mean, the highscrore table will contain thousands or more rows(data)?? Can you see my comment for "Robin Day"
bbtang
@bbtang I updated my response.
Elzo Valugi
I dunno know how to use cache files. And what if the user clear cache? Will it clear the highscores? Clearing highscore each month seems another solution for me... beside using cache, what other methods u have used and think its best??
bbtang
@bbtang I'm talking about server cache like memcache or APC, not user cache.
Elzo Valugi
I see.. Can you elaborate more please? I am new to it but am given this task, i need to do it carefully and choose the best way to implement it. Please help and advise me how to do it
bbtang
@bbtang I can elaborate but there are entire books wrote to cover this aspects. Your questions should be as specific and punctual as possible.
Elzo Valugi
+1  A: 

You should go with the single table option. That way when you add more games you don't need to change your database schema.

Databases are designed to cope with data like this. Having one table with a lot of data will not cause you any problems as long as it is indexed correctly.

Robin Day
I might have thousands or more rows in 1 table. If I execute "SELECT * from table WHERE...", will it have any troubles? I mean, performance wise? Does it take very long to retrieve the data?
bbtang
Indexes are there to make this all possible without performance problems. When you're looking at millions or billions of rows, then you might need to look at alternative performance options. However, its unlikely to ever be splitting the data accross multiple tables.
Robin Day
"However, its unlikely to ever be splitting the data accross multiple tables" this line makes me drop my "mutliple tables" idea. Well, i will look into the indexes. So to summarize, you would choose 1 table with indexes instead of multiple tables right?
bbtang
Oh ya, by the way, if using 1 table. If 10 or maybe 100 users submit on the same time (submit to a same table), will there be any problems?
bbtang
No. Databases are designed to handle concurrency. As long as you don't have any glaring code bugs, the database should handle this case perfectly; at most, some users would experience a few [milli]seconds delay.
Cide
@bbtang you can use transactions to be sure the ACID is respected
Elzo Valugi