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
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