Triggers vs Views in MySQL

Question

We are in the process of denormalizing a large amount of data for performance reasons. Basically a Query that would normally JOIN over 10 tables is replaced with a Query that has no JOINs, yet all the necessary data is stored/cached alongside in the initial table.

I am a strong advocate of triggers that would help me keep all the data up2date absolutely transparently. There are other decision makers in the company who are against using triggers (for several reasons) and suggest building a VIEW instead in hopes that the VIEWs are already optimized for better data retrieval.

Is this the case in MySQL?

Answer 1

This depends on the MySQL version that you intend to use.

If your view is merely a Join of 10 tables, without any grouping and aggregate calculations, why do you need de-normalization at all?

If your view involves grouping and aggregates, you'll have to test the views performance against the bare queries and against a denormalized design with triggers. There is nothing better than testing with your data and your queries. However, as MySQL Performance Blog article suggests: MySQL VIEW as performance troublemaker, views are more of a way to write compact queries and reuse of code than a performance improvement. Occasionally they even have a negative impact on performance:

It is also very dangerous if you assume MySQL would optimize your VIEWs same way as more advanced database systems would. Same as with subqueries and derived tables MySQL 5.0 will fail and perform very inefficiently in many counts.

But note that this a rather old article (2007) and it certainly doesn't take into account the recent improvements on optimizer, made in MariaDB 5.3 and 5.5 (which can be used as drop-in replacements of MySQL 5.1 and 5.5). This section is relevant to your question:

Optimizations for derived tables and views

• No early materialization of derived tables (e.g. subqueries in a FROM clause) and materialized views (EXPLAIN is always instantaneous)
• Thanks to Derived Table Merge optimization, mergeable derived tables are now processed like mergeable VIEWs.
• Derived Table with Keys optimization gives the optimizer an option to create indexes over materialized derived tables
• Fields of merge-able views and derived tables are involved now in all optimizations employing equalities

Another feature that MariaDB has implemented is VIRTUAL PERSISTENT columns which can be helpful for having certain calculations stored in tables, without using the (evil) triggers.

(Sidenote: one problem in MySQL with triggers is that when mixed with cascading Foreign key constraints, they are not activated by cascading actions MDEV-11472).

MySQL 5.6 also has improvements on the optimizer regarding views and derived tables but I have no idea when a stable release will be out.

To summarize, I think you should carefully consider which version you will implement your database on and if possible test the various design options in the available versions (MySQL 5.1 (and 5.5), MariaDB 5.3 (and 5.5), MySQL 5.6(under development)).