According to Wikipedia, “a database trigger is procedural code that is automatically executed in response to certain events on a particular table or view in a database. The trigger is mostly used for maintaining the integrity of the information on the database.”
In practical terms, what does that do for you though? What that means is that when you want something to happen every time someone makes a specific change to a table or view, a trigger is placed on that table or view. That trigger will call a function when the conditions for the trigger are met.
You may be asking yourself, why would you want to have something happen without the caller specifically asking for it and possibly happening without their knowledge? In short, adding a trigger saves people from forgetting to do that action, and ensures consistent rules are applied.
Of course, nothing comes without a cost. Triggers have overhead and there might be times when you don’t want it to fire and you have to work around it. But if properly designed, these situations should be rare — often in very specific situations where there is a valid reason to make the exception.
A trigger has already been built in this exercise behind the scenes for you. What you are going to do in this exercise is activate this trigger and see the impact it has on your data.
First check the starting state of the
customers table before we make any changes. A
SELECT * on this table will be good.
UPDATE statement on the
customers table to
years_old column to
42 for any customer with a
SELECT statement again after your
UPDATE statement and notice that more changed than what you had in your
UPDATE statement. A trigger made this additional change.