views:

138

answers:

6

Is it possible to have a webbased PHP/mySQL game, where each user has his own database with data about his/her account.

It's a singleplayer management game where each user will need to have their own database. Or atleast, that's the way I see this. Is this the right solution, and will this work in terms of server bandwidth and such.

You can look at it as a savefile for the game. Every user has a savefile, his own database. The game's fundamentals are all stores in 1 database. The savefile database only consists of standings, generated characters and things that make his savefile/game unique.

+8  A: 

Is it possible : yes. But is it the right solution : most definitely no.

Suppose you want to update a table, using your proposed approach you would have to modify a gazillion number of databases, instead of just one. See the problem?

wimvds
Each user in a system will need their own entity for storing their associated information but that's exactly what a row is in one table in one database, there is no need for that high of a level of separation. +1
Cryo
A: 

You wouldn't want to setup a database for every user that would be mad, you'd want 1 master and some slave databases in order to scale effectively.

fire
A: 

Sounds very unlikely - and not specifically for game. A table per user would be strange, and a column per user would be too ...

Unless your game is something like phpmyAdmin, in which case one database per user won't be enough!

MatthieuP
A: 

While this might work for up to 10 or so users, for 200+ the solution becomes messy and unmanageable.

Why can't you use separate rows in a single database to store details of different players?

C.

symcbean
A: 

Maybe you put it wrong. If you want some local storage than you can have a local database in each client machine or DOM storage or SQLite database.

Elzo Valugi
+5  A: 

You should read some more information on relational databases. Then think about it a bit more. You do not need to create separate databases, nor separate users. You should have one users table, each user having a primary key id, and then other tables representing other bits of data each have an owner or userid column (whatever you want to name it), where each row puts the ID of its owner.

For example, if you want to store a player's inventory, you'd have a table called InventoryItems, and columns "id, userid, itemtypeid, numberOfItems". The itemtypeid is the ID of a row in the ItemTypes table, with columns for things like image, name, stats of that type of item. Then each item in an user's inventory has one row in that table.

This is pretty basic database design and I think you are much too accustomed to flat files. So again, I urge you to read up more on your database system and relational database design in general, to learn techniques such as one-to-many relationships, many-to-many relationships (via linking tables), things like that. As you read, you will probably have many "ah-ha" moments where you think of new ways to solve your problems.

Or, you know, go back to flat files. That would work too...

Ricket