The scope of this tutorial is to introduce you some of the CUBRID features regarding database triggers, by showing some examples of creating and using triggers in CUBRID.

Overview

“A database trigger is procedural code that is automatically executed in response to certain events on a particular table or view in a database.” (http://en.wikipedia.org/wiki/Database_trigger).

Database triggers can be very useful for:

1. Control users’ changes in the database
2. Log/Audit users’ changes
3. Implement and enforce business rules
4. Perform various actions automatically
5. Improve performance in client/server environment (triggers run on the server side, before the results is returned to the client).

Many database systems have nowadays support for triggers, usually using their own specific implementation of SQL-based dialects. CUBRID has an implementation which also uses SQL-based statements to define the triggers actions.

In CUBRID, we have 2 types of triggers:

1. User triggers
2. Table triggers

Triggers can be defined for combinations of:

3. Events: INSERT, UPDATE, DELETE etc.
4. Activation time: BEFORE, AFTER, DEFFERED
5. Action type: REJECT, STATEMENT etc.
6. Trigger target (tables)

You can find all the details about triggers in the CUBRID manual: http://www.cubrid.org/manual/840.

We will assume in this tutorial that the reader is already familiar with the basics of triggers in CUBRID and we will focus only on presenting some concrete examples of using this feature.

Setup tutorial data

Let’s create the following 2 tables, to implement a very simple “virtual library”:

7. Authors
8. Books

The relation between them is 1:0-n - for each book we can have multiple books (or no books at all) in the library.

Here are the SQL statements to execute:

And now, let’s insert some startup data in these tables:

Before we proceed to the next sections, we remind you that it is very important, when defining triggers, to understand the relation between activation time and the new, old and obj qualifiers:

A Data Update trigger

Let’s start by creating a trigger which will automatically update the “notes” column for an author, when a new book is added in our library. We will need to “intercept” the INSERT operations in the “books” table and, AFTER the INSERT is done, UPDATE the “notes” column from the “authors” table.

This is the code of the trigger which performs this operation:

If you use the CUBRID Manager client to create the trigger, here below is the definition of the trigger:

If everything goes ok, the user will be notified that the trigger was successfully created.

Now, let’s add a new book in the library:

The trigger we created will intercept this action and will update the “books” table, as desired:

A Data Validation trigger

Now, we will create a trigger which will automatically verify that whenever we add a new book in our library, the “published_date” is a later date than the author “born_date”.  We will need to “intercept” the INSERT operations in the “books” table and, BEFORE the INSERT is done, compare the values of the date in the both tables. If the validation fails, the trigger should REJECT the INSERT.

This is the code of the trigger:

In the CUBRID Manager client, the trigger can be created as shown below:

And now, let’s see the trigger in action:

The trigger we created has intercepted this invalid action and denied it:

The trigger canceled the INSERT, because the automatic validation we setup previously has failed.

Another Data Update trigger

Finally, we will create a trigger which will automatically update the number of the books published by the author, after a book is removed (delete) from the library.  We will need to “intercept” the DELETE operations in the “books” table and, and, AFTER the INSERT is done, UPDATE the “books_count” column in the “authors” table.

Here is the code of this trigger:

The trigger definition in the CUBRID Manager client is:

Let’s test what happens when we delete a book. Let’s first add a new author, with one book in the library:

Now, we will delete the book:

The trigger we created will intercept the “books” DELETE and will update the “authors” table (will set “books_count” value to 0):

Other things to know about CUBRID triggers

Enable/Disable triggers

A trigger can always be enabled or disabled. You can achieve this by using the ALTER TRIGGER statement:

Or

Trigger(s) priority

Triggers in CUBRID have a “special” attribute, called PRIORITY. This attribute is used whenever there are multiple triggers that will be executed for the same event, to determine the execution order. PRIORITY can have any non-negative float value between 00.00 and 9999.99, with 0 being the highest priority. If all the triggers have the same priority, the execution order is random.

You can always use the ALTER TRGGER statement to change a trigger priority:

Trigger execution log

You can view the execution log of a trigger by using the SET TRIGGER TRACE statement:

Let’s try this with the trigger t_update_notes:

User rights & Triggers

In CUBRID, there is no dedicated GRANT statement for triggers (like in MySQL or ORACLE. In particular, in MySQL it is the TRIGGER privilege which enables trigger operations. You must have this privilege for a table to create, drop, or execute triggers for that table).

In CUBRID the following rules apply:

9. A table trigger is visible to all users who have the SELECT privilege on the trigger target table.
10. To create a table trigger, the user must have an ALTER authorization on the table.

Triggers potential (down) side effects

Defining (and using) triggers, beside the many useful things they can achieve, can have possible downside effects as well, and the user should know about this, before taking any decisions regarding triggers usage.

Such potential downside effects can be:

11. Database performance slow-down. Imagine that you have a trigger which runs a slow SQL statement, and the trigger is executed for each UPDATE on a heavy-traffic table/column. Such a trigger will have a significant impact on the database performance.
12. Watch out for recursive triggers!  Such triggers might even cause the current session close! Be very careful when defining triggers that modify the same table for which the trigger has been triggered!
13. Triggers should not be used to “hide” database design flaws! Do not use triggers to replace CASCADE constraints, or FOREIGN KEY references, for example.
14. Triggers are usually hard to migrate between different databases.

Links & Resources

This concludes the first CUBRID Triggers tutorial. We will return soon with another tutorial about “user triggers” in CUBRID! Please let us know your feedback and remember to periodically check the CUBRID web site – www.cubrid.org/tutorials - for other tutorials and resources.

Thank you!