Creating Triggers to check conflicts - oracle

Question

My task is to check there are no conflicts with day and time when you insert or update a group fitness class on a customer timetable. Can someone please help me out. These are the tables I've got:
Name Null Type
------------- -------- ------------
CUSTOMER_T_ID NOT NULL NUMBER(38)
C_DATE NOT NULL TIMESTAMP(6)
TIMETABLE_ID NOT NULL NUMBER(38)
CUSTOMER_ID NOT NULL NUMBER(38)
Desc Timetable
Name Null Type
----------------- -------- ------------
TIMETABLE_ID NOT NULL NUMBER(38)
CLASS_DAY NOT NULL VARCHAR2(50)
CLASS_LOCATION NOT NULL VARCHAR2(50)
CLASS_START_TIME NOT NULL TIMESTAMP(6)
CLASS_FINISH_TIME NOT NULL TIMESTAMP(6)
WORKOUT_CLASS_ID NOT NULL NUMBER(38)
TRAINER_ID NOT NULL NUMBER(38)
Desc Workout_class
Name Null Type
---------------- -------- -------------
WORKOUT_CLASS_ID NOT NULL NUMBER(38)
NAME NOT NULL VARCHAR2(20)
WORKOUT_TYPE NOT NULL VARCHAR2(200)
EQUIPMENT_USED NOT NULL VARCHAR2(200)
RESULTS NOT NULL VARCHAR2(200)
COST NOT NULL FLOAT(126)
INTENSITY_LEVEL NOT NULL VARCHAR2(50)
CLASS_DURATION NOT NULL NUMBER(38)
Desc Customers
Name Null Type
---------------- -------- -------------
CUSTOMER_ID NOT NULL NUMBER(38)
FIRST_NAME NOT NULL VARCHAR2(50)
LAST_NAME NOT NULL VARCHAR2(50)
AGE NOT NULL NUMBER(38)
ADDRESS NOT NULL VARCHAR2(100)
CITY NOT NULL VARCHAR2(50)
MOBILE_PHONE NOT NULL NUMBER(10)
EMAIL VARCHAR2(50)
PICTURE BFILE()
CUSTOMER_TYPE_ID NOT NULL NUMBER(5)
Trigger is compiling but when i try to insert the same customer to the same timetable he is already into its not raising an error but the row is inserted
create or replace trigger timetableconflict
before insert or update on customer_timetable
for each row
begin
if :new.customer_T_ID = :old.Customer_T_ID and :new.Customer_ID = :old.Customer_ID
then
raise_application_error(-20000,'customer cannot enrol into same class again');
end if;
end;

Answer 1

Your trigger is comparing the OLD and NEW pseudorecords. When you insert a new row there is no OLD row in the table so all the fields in that record are null; your comparison therefore doesn't match. (You can't compare anything with null but that's a separate discussion). The condition you've used can never be matched on insert. When you update you're comparing the existing value for the field in the row being updated, with the new value you're updating it too; so you're currently saying that an update must change the customer_t_id and customer_id. Aside from anything else it looks like customer_t_id is probably supposed to be a primary key, so changing that would normally not be a good idea.
So I think you're misunderstanding what OLD represents. It looks like the customer_t_id reference is a mistake and you're trying to make sure there is not already a record for the customer in the table - but OLD does not tell you that as it only refers to the current row affected by the statement, not any other rows in the table.
I don't think that's actually your end goal from what you said in the question - I think you don't want a customer to have the same timetable twice.
Given that OLD doesn't do what you want, you might think about querying the table to see if such a row already exists. But you can't (easily) do that in a trigger; if you're inserting or updating more than one row at a time then you'll get a mutating table error. It's easy to abuse triggers by trying to make them do something they weren't designed for.
The normal way to enforce that uniqueness is with a unique constraint (or "unique composite key") rather than a trigger:
alter table customer_timetable
add constraint timetableconflict unique (customer_id, timetable_id);
That will also create a unique index to back it up; you could just create a unique index directly but declaring a constraint is more explicit. (It's not a great constraint name but I've just copied what you were going to call the trigger).
You can read more about how triggers and constraints differ:
Constraints are easier to write and less error-prone than triggers that enforce the same rules. However, triggers can enforce some complex business rules that constraints cannot. Oracle strongly recommends that you use triggers to constrain data input only in these situations:
To enforce referential integrity when child and parent tables are on different nodes of a distributed database
To enforce complex business or referential integrity rules that you cannot define with constraints
What you're describing doesn't fall into those categories.