Question

I have an existing database that is structured as follows:

user
user_profile
user_permissions
user_statistics

Each table has a unique column which is used to join each table together, as follows:

SELECT *
FROM user
INNER JOIN user_profile ON user.user_id = user_profile.user_profile_id
INNER JOIN user_permissions ON user.user_id = user_permissions.user_permissions_id
INNER JOIN user_statistics ON user.user_id = user_statistics.user_statistics_id
WHERE user_id = 1

Is there anything wrong with doing things this way or is it better practice to create one table with lots of columns, so that no joins are required?

Answer 1

This is a classic database design; it’s called “normalization“, and is generally considered best practice.

There are reasons to de-normalize a database – performance is the classic. However, that typically comes at the expense of maintainability and consistency. It usually only makes sense at the very extremes of data size – the schema you describe should scale to huge numbers of records without the joins becoming a problem.

I’m also guessing that several of the tables linked to “user” have more than one record for a given user – “statistics” typically has lots of rows for a given user; permissions may also have one row for each user’s permission. Modelling that in a single big table would be horrible.

Some designers like to create separate tables for data that is logically separate. So, your design may include a “user_profile” table with a single row per user because the designer felt that this is logically separate data from “user” – it changes under different business circumstances, for instance. This is mostly a matter of style, in my view.

Joins do not make your database slower in this case – the whole point of a relational database is to be very efficient at managing this kind of scenario (“relational” refers to the fact that data can be related).