Question

Thinking about a re-design for a database. Wondering what the differences/caveats are to something like:

users    fields  
-----    ------
id       id
         user_id
         page_id
         field_id
         field_data

as opposed to

users    address  
-----    ------
id       id
         user_id
         street1
         street2
         etc...

Are there issues with using the former that I’m not considering? Is there a performance hit if/when the fields table were to become huge? Is this just bad practice? For some reason this makes me think of nosql, but I could be mistaken.

Thanks!

Answer 1

It’s not entirely clear what you’re showing, but I’ll hazard a guess that the first design doesn’t list the specific address columns, so the idea is to be more generic. The first design will be easier to extend – instead of adding columns, you’re just adding a new field_id, and field data. Having said that you and others using it may find it more of a pain to work with…

Instead of something like:

SELECT street1, street2, city, postal_code FROM address where user_id = someval

you’ll do:

SELECT field_id, field_data FROM fields WHERE field_id in 
('street1', street2', 'city', 'postal_code') 
AND user_id = someval

In the first case it may be easier in a program to assign variables to the results, in the second case it may be a bit more of a pain (depending on the language), since you may have to test each field_id to see what it contains.

In most cases, I think you should just go with the second approach – especially if you know in advance what most of the fields are. The first approach is more for when you think you’ll need to add many previously-unknown, and unknowable fields later.