“MySQL Stored Procedure Programming” by Guy Harrison in the Triggers chapter says that triggers is the way to go to maintain a summary table.
The summary table in the example here is a table which stores a total value of sales for a customer. This data is derived from a ‘sales’ table which records individual transactions. The example uses uses BEFORE INSERT, BEFORE UPDATE and BEFORE DELETE triggers on the ‘sales’ table to keep ‘customer_sales_totals’ table in sync. The BEFORE INSERT trigger performs a select on the ‘customer_sales_totals’ table and inserts a row there or updates an existing one.
Now, let’s assume that:
- there are tens/hundreds of thousands records inserted into the ‘sales’ table each day;
- it is enough if the ‘customer_sales_totals’ is never out of date by more then few minutes;
- there a many sales for each customer (the number of sales is much bigger than the number of customers).
In this scenario would a periodic low priority job rather than triggers be a more efficient way of maintaining the ‘customer_sales_totals’?
Thanks
Tymek
I personally favor the periodic job option for the sake of maintenance. The code is located in one place, can be more easily documented, and tests can be carried out more easily.
Now, I know that triggers have their fans and it is certainly more subtle, although in my opinion it lead to split the code in too many pieces. In real daily work life this means you need an expert to look at it, so less flexibility in organizing your staff and more head scratching when you hit a bug.