Question

So I started working for a company where they had 3 to 5 different tables that were often queried in either a complex join or through a double, triple query (I’m probably the 4th person to start working here, it’s very messy).

Anyhow, I created a table that when querying the other 3 or 5 tables at the same time inserts that data into my table along with whatever information normally got inserted there. It has drastically sped up the page speeds for many applications and I’m wondering if I made a mistake here.

I’m hoping that in the future to remove inserting into those other tables and simply inserting all that information into the table that I’ve started and to switch the applications to that one table. It’s just a lot faster.

Could someone tell me why it’s much faster to group all the information into one massive table and if there is any downside to doing it this way?

Answer 1

If the joins are slow, it may be because the tables did not have FOREIGN KEY relationships and indexes properly defined. If the tables had been properly normalized before, it is probably not a good idea to denormalize them into a single table unless they were not performant with proper indexing. FOREIGN KEY constraints require indexing on both the PK table and the related FK column, so simply defining those constraints if they don’t already exist may go a long way toward improving performance.

The first course of action is to make sure the table relationships are defined correctly and the tables are indexed, before you begin denormalizing it.

There is a concept called materialized views, which serve as a sort of cache for views or queries whose result sets are deterministic, by storing the results of a view’s query into a temporary table. MySQL does not support materialized views directly, but you can implement them by occasionally selecting all rows from a multi-table query and storing the output into a table. When the data in that table is stale, you overwrite it with a new rowset. For simple SELECT queries which are used to display data that doesn’t change often, you may be able to speed up your pageloads using this method. It is not advisable to use it for data which is constantly changing though.

A good use for materialized views might be constructing rows to populate your site’s dropdown lists or to store the result of complicated reports which are only run once a week. A bad use for them would be to store customer order information, which requires timely access.