Thread: users table and user_details table? Bad form?
I have a users table that's getting pretty large (~ 2M rows) and that's
very sparse, because most users register but don't do much, so a lot
of the columns are NULL.
I'm thinking of adding a user_details table with a unique foreign key
constraint to the users table, and moving all those rarely populated
columns into it. A row in user_details would only be created it we need
to populate one or more of the columns in there.
Is that an okay idea?
It doesn't violate any normalization rules, does it?
And in practice, does it cause any problems?
Thanks.
very sparse, because most users register but don't do much, so a lot
of the columns are NULL.
I'm thinking of adding a user_details table with a unique foreign key
constraint to the users table, and moving all those rarely populated
columns into it. A row in user_details would only be created it we need
to populate one or more of the columns in there.
Is that an okay idea?
It doesn't violate any normalization rules, does it?
And in practice, does it cause any problems?
Thanks.
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now. Join in!
On Nov 28, 2007 1:37 AM, plu tard <plutard12@hotmail.com> wrote:
That sounds like a good idea.
Sean
I have a users table that's getting pretty large (~ 2M rows) and that's
very sparse, because most users register but don't do much, so a lot
of the columns are NULL.
I'm thinking of adding a user_details table with a unique foreign key
constraint to the users table, and moving all those rarely populated
columns into it. A row in user_details would only be created it we need
to populate one or more of the columns in there.
Is that an okay idea?
It doesn't violate any normalization rules, does it?
And in practice, does it cause any problems?
That sounds like a good idea.
Sean