I'm working on a web app in which each user will have their own account. Each account would have its own data (duh) and this data needs to be kept separate from everyone else (either by putting it in another database JUST for that user or combining all data into 1 database and then marking it with a "userid" that can be used to filter out every one else stuff.

Which would be better: having a different database for every user (created on signup via sql and php) that is named after their userid? Or is it better to combine all of the info into one massive database and just earmark things with an indexed "userid"?

Thanks

Performance might be an issue in the future so which is better for that?

i don't think speed is necessarily going to be an issue, just be sure to make fk and primary keys, and indexes where necessary and you should be good using a single db

on top of that, it would be a nightmare for multiple databases, multiple upgrade scripts, i would most likely advise against it unless its truly a distributed application

Thanks for the reply. Yeah, I had considered that upgrading the app later might be a nightmare trying to process 1,000 different databases rather than changing just 1 big one (or at least it would be somewhat resource-intensive)

If I did a bunch of different databases (one for each account) then each database would also have a unique mysql user/pass. I was thinking it might be more secure so that each account can only access THEIR data in THEIR database rather than all data (using permissions). If someone could somehow find a way to hack in and get the universal msyql username/pass then I'm screwed b/c everything is in 1 place.

But using unique dbs and user accts, in order to hack into all data a person would have to get ALL the usernames/passwords which would be near-impossible.

Again, I really appreciate feedback

you can specify sql user accounts and ip addresses if need be

Someone once posted the analogy that a different database for every record is like a different hard drive for every file.