Question

Say I have a table like this:

  create table users (
   user_id int not null auto_increment,
   username varchar,
   joined_at datetime,
   bio text,
   favorite_color varchar,
   favorite_band varchar
   ....
 );

Say that over time, more and more columns — like favorite_animal, favorite_city, etc. — get added to this table.
Eventually, there are like 20 or more columns.

At this point, I’m feeling like I want to move columns to a separate
user_profiles table is so I can do select * from users without
returning a large number of usually irrelevant columns (like
favorite_color). And when I do need to query by favorite_color, I can just do
something like this:

select * from users inner join user_profiles using user_id where
user_profiles.favorite_color = 'red';

Is moving columns off the main table into an “auxiliary” table a good
idea?

Or is it better to keep all the columns in the users table, and always
be explicit about the columns I want to return? E.g.

select user_id, username, last_logged_in_at, etc. etc. from users;

What performance considerations are involved here?

Answer 1

Don’t use an auxiliary table if it’s going to contain a collection of miscellaneous fields with no conceptual cohesion.

Do use a separate table if you can come up with a good conceptual grouping of a number of fields e.g. an Address table.

Of course, your application has its own performance and normalisation needs, and you should only apply this advice with proper respect to your own situation.