What if your database could handle important tasks all by itself right after data changes?
Why AFTER trigger execution in SQL? - Purpose & Use Cases
Imagine you run a busy online store. Every time a customer places an order, you have to manually check the order, update inventory, and send a confirmation email. Doing all this by hand after each order is overwhelming and easy to forget.
Manually handling these tasks is slow and prone to mistakes. You might forget to update stock or delay sending emails. This causes unhappy customers and lost sales. It's like trying to juggle many balls at once and dropping some.
AFTER triggers automatically run right after a database change, like inserting an order. They handle follow-up tasks instantly and reliably, so you never miss a step. This keeps your data accurate and your customers happy without extra effort.
Insert order; Then manually update stock; Then send email;
CREATE TRIGGER after_order_insert AFTER INSERT ON orders FOR EACH ROW BEGIN UPDATE stock SET quantity = quantity - NEW.quantity WHERE product_id = NEW.product_id; -- example update statement; -- SEND email; -- sending email is usually handled outside the database END;
AFTER triggers let your database do the follow-up work automatically, making your system smarter and more dependable.
When a new user signs up, an AFTER trigger can automatically add them to a welcome email list and log their signup time without you lifting a finger.
Manual follow-up tasks are slow and error-prone.
AFTER triggers run automatically after data changes.
This ensures important actions happen reliably and quickly.
Practice
AFTER trigger in SQL?Solution
Step 1: Understand the timing of AFTER triggers
AFTER triggers run only after the main data change operation completes successfully.Step 2: Identify the purpose of AFTER triggers
They automate tasks like logging or updating related data after changes, ensuring consistency.Final Answer:
To execute actions only after a successful data change like insert, update, or delete -> Option AQuick Check:
AFTER trigger = post-change action [OK]
- Confusing BEFORE and AFTER triggers
- Thinking AFTER triggers run before data changes
- Assuming AFTER triggers rollback transactions
Solution
Step 1: Recall standard AFTER trigger syntax
The correct syntax starts with CREATE TRIGGER, followed by trigger name, timing (AFTER), event (INSERT), and table name.Step 2: Check each option
CREATE TRIGGER trg AFTER INSERT ON table_name BEGIN ... END; matches the correct syntax. Options A, B, and C have wrong order, timing, or event.Final Answer:
CREATE TRIGGER trg AFTER INSERT ON table_name BEGIN ... END; -> Option BQuick Check:
CREATE TRIGGER + AFTER + INSERT = correct syntax [OK]
- Mixing BEFORE and AFTER keywords
- Placing AFTER in wrong position
- Using DELETE event instead of INSERT
CREATE TABLE sales (id INT, amount INT);
CREATE TRIGGER trg AFTER INSERT ON sales
BEGIN
INSERT INTO audit_log VALUES ('insert', NEW.id, NEW.amount);
END;
What happens when you run
INSERT INTO sales VALUES (1, 100);?Solution
Step 1: Understand the trigger action
The AFTER INSERT trigger inserts a row into audit_log using the new sales row data.Step 2: Analyze the insert command effect
Inserting into sales triggers the AFTER INSERT, so both sales and audit_log get new rows.Final Answer:
New rows are added to both sales and audit_log -> Option AQuick Check:
AFTER INSERT triggers run after insert, adding audit_log row [OK]
- Thinking trigger replaces original insert
- Assuming trigger runs before insert
- Ignoring NEW keyword usage
CREATE TRIGGER trg AFTER UPDATE ON employees
BEGIN
UPDATE employees SET salary = salary * 1.1 WHERE id = NEW.id;
END;
What problem will occur when you update an employee's salary?
Solution
Step 1: Analyze trigger logic
The trigger updates the same table it is triggered on, causing the trigger to fire again.Step 2: Identify the effect of recursive updates
This causes an infinite loop of updates, eventually causing stack overflow or error.Final Answer:
Infinite loop causing stack overflow -> Option DQuick Check:
Trigger updating same table without stop = infinite loop [OK]
- Not realizing trigger recursion
- Expecting trigger to run once only
- Ignoring NEW and OLD references
orders table into orders_log only if the delete succeeds. Which is the best way to do this using an AFTER trigger?Solution
Step 1: Understand timing for logging deletes
AFTER DELETE triggers run only after the delete succeeds, ensuring accurate logging.Step 2: Choose correct trigger type
Creating an AFTER DELETE trigger on orders to insert into orders_log captures deleted data reliably.Final Answer:
Create an AFTER DELETE trigger on orders that inserts deleted row info into orders_log -> Option CQuick Check:
AFTER DELETE trigger logs only successful deletions [OK]
- Using BEFORE DELETE triggers which may log failed deletes
- Confusing INSERT triggers with DELETE triggers
- Trying to delete from log table after orders delete
Ready to prove it?
Pass the test and this pattern moves unknown
