In what cases would or wouldn't you use database triggers instead of a script called by cron?

Question

A fully normalized database with no redundant data is good "academically", but has terrible real-world performance.

The first optimization is obviously a cache system. After this, for creating redundant data for performance, when or why would (or wouldn't) you use triggers over a cron task that calls a script to update the redundant data?

Answer 1

Not a MySQL guy, but the concept should port...

Basically, a cron job is a scheduled job (however frequently you want that run), and a trigger is... well... triggered. In general, you would use any kind of scheduling (Cron, scheduled jobs (in the MS Sql world), etc.) when the task you want is one or both of:
* Not Time Sensitive
* Process Intensive.

For anything that is time sensitive and not process intensive, you'd use a trigger.

For those cases where something is both time sensitive and process intensive, you have to decide which is more important (or handle the crunching outside of SQL in code somewhere).