The previous two parts have looked at some solutions offered by triggers. Let's look now at some wishful triggers solutions, which are currently unavailable because of triggers limitations.
Limitations and wishful features
Triggers are slow
The overhead of adding triggers is usually an even breaker. But I would like to believe speed will improve in time!
Triggers cannot act on the same table which activated them.
A thing I would like to do is have a rotating table. A log table is a perfect example: I only want to store logs up to 7 days back, or up to 1M rows. ON INSERT, (or once every 1000 inserts or so), I wish to remove oldest rows. This is not possible today since I can't DELETE rows from the same table which caused the ON INSERT trigger to run. It can't be hacked by calling on another table, then doing a circular trigger trick. MySQL will raise an error on run time, complaining about a loop.
Triggers cannot act on system tables.
Now why would I want to do that? Well, one of the first things I look at when reviewing a database is the users grants. I always find a list of users which is just too permissive, with far too many users than required. I once came upon a database with 273 users, where only 5 of them were actually in use. "When were these added?", I asked - but nobody knew.
I would love to have an ON INSERT and an ON UPDATE trigger on the mysql.user table, which lists down the time of user creation and the invoking user (who would usually be 'root') and host, so it's easier to track down who did what.
You cannot execute prepared statements from within a trigger.
Not much to add here. The possibilities are too many.
You can't spawn an ANALYZE TABLE from a trigger
What I want to do is to run an ANALYZE TABLE once every 10K inserts or deletes, so the table takes care of itself. I've tried hacking this with prepared statements (you can't use them); with cursors (you can only run a cursor on SELECT queries) or otherwise SQL hacks (none worked). If anyone finds a hack around it - please let me know!
You can't have more than one trigger on the same event per table
This is more of a design issue. If I want to have two things BEFORE INSERT on City, I need to code both in the same trigger. This means adding functionality involves editing existing, tested, working code. It would be much nicer if two such triggers could play along.
A dirty workaround to problematic issues
There is a dirty workaround to some issues.
Take, for example, the rotating tables problem. Instead of the trigger executing the following query:
DELETE FROM logs WHERE time < DATE_ADD(NOW(), INTERVAL -7 DAY)
(as we've already noted was impossible), the triggers can write down the query as TEXT into some queries_to_run table. A cronjob can periodically check this table and execute whatever is in it, removing executed rows.
MySQL 5.1's event scheduler can also be used for such statements which are invokable (like said DELETE).