Question

I am creating a database that will store 100.000 (and probably more in the future) users. While this obviously happens in a table with 1 row per user, every user can (and will) store hundreds of items. In programming language this would mean the user has 2 arrays (or one 2-dimensional array) of integers: a column for the itemid’s and a column for the amounts.

My instincts tell me to create a table to hold all these items, with rows like (userid, itemid, amount). However this would result in a huge table. 200.000 users with 250 items each… that’s 50 million entries in one table. This, plus the fact that the table will undergo continuous and rapid change, frightens me. (How rapid? I estimate up to 100 modifications per second.)

Typically there will be anywhere between 100 and 2000 users, all adding and removing items, and modifying amounts. These actions can and will happen in programming code. It would go as follows:

• User starts session, program loads all the users items from the database
• User modifies the item list
• Every few minutes, the changes are saved into the database
• When the user ends the session, it is also saved into the database

It is worth noting that there is a maximum to the number of items a user can store.

Are there any alternatives to using a separate table? Perhaps save the values in a formatted text string? Or is this one of the instances where using a MySQL database is actually a Bad Idea™?

Thank you for your time and insights.

Answer 1

My instincts tell me to create a table to hold all these items

Your instincts are right.

1) avoid premature optimisation

2) don’t break the rules of normalization unless you’ve got a very good and real reason to do so

3) why do you suspect that the multi-table approach will be faster?

that’s 50 million entries in one table

So what? Even if you only have an index on userid, the difference in performance compared with a single table per user will not be noticeably slower (in practice, with 200,000 users, it will be much, much faster – since the DBMS can comfortably keep an open file handle for each table!).

I estimate up to 100 modifications per second

Should be possible using MySQL and fairly basic hardware, but if it were me, and I wanted a bit of headroom, I’d go with a pair of mirrored SATA disks, tables on one mirror, indexes on the other.

The only issue I’d be concerned about (which applies regardless of which of the 2 models you choose) is supporting 2000 concurrent connections. Do the connections have to be concurrent? Or can each user download a working set (optionally using an optimistic locking strategy) and close off the connection, then push back the changes on a new connection? If not, then you’ll probably want a good whack of memory and CPU.

But leaving aside whether to use one big table or lots of little ones, if this is the only use for the data, and access is not concurrent to particular data items, then why bother with a relational database at all? NoSQL or a shared filesystem might work just as well.