NYCPHP Meetup

[Hans Zaunere]

jim.bishop wrote:

> I'm designing a new user database for a personal project, and I was toying
> with a different method of storing the data than I have used before.
> Usually I create tables with logical column names that reference the data
> in the column.
> 
> For Example:
> 
> ---------------
> | User        |
> ---------------
> | id          |
> | first_name  |
> | last_name   |
> | email       |
> 
> ...
> ---------------
> 
> But this becomes cumbersome when you have to add fields to the table.  I
> have designed a new table structure that looks like this:
> 
> 
> ---------------
> | User        |
> ---------------
> | uid         |
> ---------------
> 
> -----------------
> | UserAttribute |
> -----------------
> | attribute_id  |
> | uid_fk        | * foreign key to user table
> | attribute     |
> | value         |
> -----------------
> 
> Okay.  So I've built many user databases before and never employed the
> system below.  Has anyone else?  Besides the requisit JOIN that has to be
> called with every SELECT, what is the downsides to using this kind of
> architecture?

I've done the "normalize to the point of abnormality" and personally don't find it worth; especially in this type of situation.  Normalization can be cumbersome in its own way and every environment (and developer) warrants a balance between the two.

H