Best way to add content (large list) to relational database

Question

I apologize if this may seem like somewhat of a novice question (which it probably is), but I'm just introducing myself to the idea of relational databases and I'm struggling with this concept.

I have a database with roughly 75 fields which represent different characteristics of a 'user'. One of those fields represents a the locations that user has been and I'm wondering what the best way is to store the data so that it is easily retrievable and can be used later on (i.e. tracking a route on Google Maps, identifying if two users shared the same location etc.)

The problem is that some users may have 5 locations in total while others may be well over 100.

Is it best to store these locations in a text file named using the unique id of each user(one location on each line, or in a csv)? Or to create a separate table for each individual user connected to their unique id (that seems like overkill to me)? Or, is there a way to store all of the locations directly in the single field in the original table?

I'm hoping that I'm missing a concept, or there is a link to a tutorial that will help my understanding.

If it helps, you can assume that the locations will be stored in order and will not be changed once stored. Also, these locations are static (I don't need to add any more locations once as they can't be updated).

Thank you for time in helping me. I appreciate it!

Answer 1

The most common way would be to have a separate table, something like

USER_LOCATION
+------------+------------------+
|  USER_ID   |   LOCATION_ID    |
+------------+------------------+
|            |                  |

If user 3 has 5 locations, there will be five rows containing user_id 3.

However, if you say the order of locations matter then an additional field specifying the ordinal position of the location within a user can be used.

The separate table approach is what we call normalized.

If you store a location list as a comma-separated string of location ids, for example, it is trival to maintain the order, but you lose the ability for the database to quickly answer the question "which users have been at location x?". Your data would be what we call denormalized.

You do have options, of course, but relational databases are pretty good with joining tables, and they are not overkill. They do look a little funny when you have ordering requirements, like the one you mention. But people use them all the time.

Answer 2

Store the location data for the user in a separate table. The location table would link back to the user table by a common user_id.

Keeping multiple locations for a particular user in a single table is not a good idea - you'll end up with denormalized data.

You may want to read up on:

• Referential Integrity
• Relational denormalization

Answer 3

In a relational database you would use a mapping table. So you would have user, location and userlocation tables (user is a reserved word so you may wish to use a different name). This allows you to have a many-to-many relationship, i.e. many users can visit many locations. If you want to model a route as an ordered collection of locations then you will need to do more work. This site gives an example