Reputation: 167
I am working on a project using MySQL and PHP. I will have many (hundreds to thousands, possibly) users, and each user will have many (several thousand) entries relating to him/her. I was initially thinking of sticking all of the entries into one table, and having one of the columns be the user ID which the entry corresponds to, but this table would become huge, and likely hard to manage. I'd need to query the table frequently to get the entries which correspond to a particular user ID, and this may take a while. However, I would rarely need to query data that doesn't share a user ID.
I am now thinking about making a table for every user ID (something like "table1" for userID one, for example), and then just querying the individual tables. However, having thousands of tables sounds like a bad idea as well.
Which would you recommend? Or is there a better solution I haven't though of? (I hope my question made sense!)
Upvotes: 1
Views: 868
Reputation: 48775
The only valid way of doing that is having everything in one table. MySQL in not made for such extreme usages.
I suggest you keep all the entries in one table, each enty having UserID. And don't forget to put the index on that field.
It may be reasonable thinking about multiple tables, but if you do it that way, you queries will actually take more time, and data will use more disk space, because each table creates aditional overhead.
Go with one table, go the only vaid way. Splitting is not an option, you will just create data fragmentation, making yourself hard time when wou will want to for example do a backup.
Just a aditional comment: I have seen 20GB tables many times, but I have never seen a database with more than 100 tables.
Upvotes: 3