Question

Say I have several registered users in my website.

Users are saved on a single table ‘users’ that assigns a unique id for each one of them.

I want to allow my users to track their expenses, miles driven, temperature, etc.

I can’t be sure each user will always enter a value for all trackable variables when they login — so an example of what could happen would be:

'example data'
user     date         amount    miles     temp    etc
1        3/1/2010     $10.00    5         54
2        3/1/2010     $20.00    15          
1        3/12/2010              5         55
1        3/15/2010    $10.00    25        51
3        3/20/2010                        45
3        4/12/2010    $20.00    10        54

What is the best way to set up my tables for this situation?

Should I create a table exclusive to each user when they register? (could end up with thousands of user-exclusive tables)

'user-1 table'
date         amount    miles     temp    etc
3/1/2010     $10.00    5         54
3/12/2010              5         55
3/15/2010    $10.00    25        51

'user-3 table'
date         amount    miles     temp    etc
3/20/2010                        45
4/12/2010    $20.00    10        54

and so on...

Should I create a single table that is essentially the same as the example data above? (could end up with a gigantic table that needs to be combed to find rows with requested user id’s).

'user data table'
user     date         amount    miles     temp    etc
1        3/1/2010     $10.00    5         54
2        3/1/2010     $20.00    15          
1        3/12/2010              5         55
1        3/15/2010    $10.00    25        51
3        3/20/2010                        45
3        4/12/2010    $20.00    10        54

Any suggestions?

Answer 1

Databases are built to handle similar data as a set together.

What you want is a single user-data-table, with multiple users in the same table split by user_id. You might want to further normalize that though, so that it stores:

user     date         type      units
1        3/1/2010     dollars   10.00
1        3/1/2010     miles     5
1        3/1/2010     temp      54
2        3/1/2010     dollars   20.00
2        3/1/2010     miles     15          
1        3/12/2010    miles     5
1        3/12/2010    temp      55
etc

Or even further if the user+date makes a specific trip

trip-table
tripid    user     date
========= ======== =========
1         1        3/1/2010

type-table
typeid    description
========= ============
1         dollars
2         miles
etc

trip-data
tripid     type      units
=========  ========  =======
1          1         10.00
1          2         5
etc

However, if you will always (or almost always) show your data in the form as entered, with the data pivoted on all the input columns (like a spreadsheet), then you would be better off sticking to the un-normalised form for brevity, programmability and performance.

could end up with a gigantic table that needs to be combed to find rows with requested user id’s

Assuming you employ indexes properly and judiciously, modern RDBMS are built to handle gigantic amounts of data. The indexes allow the queries to seek only the data it needs, so there is normally little penalty in keeping it all in one table.