MySQL database design question

Posted by Greelmo on Stack Overflow See other posts from Stack Overflow or by Greelmo
Published on 2010-05-10T17:56:07Z Indexed on 2010/05/10 18:04 UTC
Read the original article Hit count: 323

Filed under:
|
|
|
|

I'm trying to weigh the pros and cons of a database design, and would like to get some feedback as to the best approach. Here is the situation:

I have users of my system that have only a few required items (username, password). They can then supply a lot of optional information. This optional information continues to grow as the system grows, so I want to do it in such a way that adding new optional information is easy. Currently, I have a separate table for each piece of information. For example, there's a table called 'names' that holds 'user_id', 'first_name', and 'last_name'. There's 'address', 'occupation', etc. You get the drift.

In most cases, when I talk to my database, I'm looking only for users with one particular qualifier (name, address, etc.). However, there are instances when I want to see what information a user has set. The 'edit account' page, for example, must run queries for each piece of information it wants.

Is this wasteful? Is there a way I can structure my queries or my database to make it so I never have to do one query for each piece of information like that without getting my tables to huge? If i want to add 'marital status', how hard will that be if I don't have a one-table-per-attribute system?

Thanks in advance.

© Stack Overflow or respective owner

Related posts about database

Related posts about design