Question

I’ve been experimenting trigger function in oracle with various constraint, recently someone recommends me to using materialized view instead of trigger on the following condition which i think is quite a wise choice to do so. But for learning purpose, i would like to know how does trigger function works.

create a trigger to check on a specify constraint base on monthly basis.

table rent

|ID|Member|book|
----------------------
1  | John |fairytale|2-jun-12| 
2  | Peter |friction|4-jun-12|  
3  | John |comic|12-jun-12|  
4  | Peter |magazine|20-jun-12|  
5  | Peter |magazine|20-jul-12|  
6  | Peter |magazine|20-jul-12|  

constraint : member are only allow to borrow 2 books monthly.

Code contributed by @HiltoN which i don’t quite understand:

create or replace trigger tr_rent
  before insert on rent
  for each row 
declare
  v_count number;
begin
  select count(id) 
    into v_count
    from rent 
   where member = :new.member;

  if v_count > 2 then 
    raise_application_error (-20001, 'Limit reached'); 
  end if;
end;

Answer 1

In general, that trigger does not work.

In general, a row-level trigger on table X cannot query table X. So, in your case, a row-level trigger on RENT is generally not allowed to query the RENT table– doing so would throw a mutating trigger exception. If you want to guarantee that your application will only ever insert 1 row at a time using an INSERT ... VALUES statement, you won’t hit a mutating trigger error but that is generally not an appropriate restriction. It is also not appropriate in a multi-user environment– if there are two transactions running at about the same time both checking out a book to the same user, this trigger will potentially allow both transactions to succeed.

The proper place to add this sort of check is almost certainly in the stored procedure that creates the RENT record. That stored procedure should check how many rentals the member has over the current month and error out if that is more than the limit. Something like

CREATE OR REPLACE PROCEDURE rent_book( p_member IN rent.member%type,
                                       p_book   IN rent.book%type )
AS
  l_max_rentals_per_month constant number := 2;

  type rental_nt is table of rent.rend_id%type;
  l_rentals_this_month             rental_nt;

BEGIN
  SELECT rent_id
    BULK COLLECT INTO l_rentals_this_month
    FROM rent
   WHERE member = p_member
     AND trunc(rental_date,'MM') = trunc(sysdate, 'MM')
     FOR UPDATE;

  IF( l_rentals_this_month.count > l_max_rentals_per_month )
  THEN
    RAISE_APPLICATION_ERROR( -20001, 'Rental limit exceeded' );
  ELSE
    INSERT INTO rent( rent_id, member, book, rental_date )
      VALUES( rent_id_seq.nextval, p_member, p_book, sysdate );
  END IF;
END;

If you really wanted to enforce something like this using triggers, the solution would get much more complicated. If you don’t care about efficiency, you could create a statement-level trigger

create or replace trigger tr_rent
  after insert on rent
declare
  v_count number;
begin
  select count(id) 
    into v_count
    from (select member, count(*)
            from rent
           where trunc(rental_date,'MM') = trunc(sysdate,'MM')
           group by member
          having count(*) > 2); 

  if v_count >= 1 then 
    raise_application_error (-20001, 'At least one person has exceeded their rental limit'); 
  end if;
end;

This works but it requires (at least) that you do the validation for every member every time. That is pretty inefficient when you have a large number of members. You could reduce the workload by substantially increasing complexity. If you

1. Create a package which declares a package global variable that is a collection of rent.member%type.
2. Create a before statement trigger that initializes this collection.
3. Create a row-level trigger that adds the :new.member to this collection
4. Create an after statement trigger that is similar to the one above but that has an additional condition that the member is in the collection you’re maintaining.

This “three-trigger solution” adds a substantial amount of complexity to the system particularly where the appropriate solution is not to use a trigger in the first place.