We have already mentioned SQL procedural extensions in Chapter 4. Being a set-based language, the SQL lacks when it comes to dealing with single records: It has very little support for conditional execution, no looping, and complete absence of all other features that are implemented in procedural languages such as Java or C#. The ability to create stored procedures inside the RDBMS provides the best of both worlds.
Stored procedure is a persistent named module containing procedural code, and trigger is a stored procedure that is executed automatically in response to certain events on a particular database object. Traditionally, triggers were tied to the database tables and would file on events such as INSERT, UPDATE, and DELETE. Later on, the concept was extended to include database-wide events such as dropping and creating database objects. One of the most obvious uses for a trigger in the context of the preceding paragraph would be to use trigger to populate identity values based upon a sequence object.
With the exception of Microsoft Access, all RDBMSs discussed in this book support the notion of triggers (and a trigger-like functionality can be simulated using MS Access built-in programming language). The devil is, of course, in the details. Every vendor and organization had implemented it differently. This is a powerful feature; unfortunately, it is beyond scope of this book.