AFTER trigger execution in SQL - Time & Space Complexity
When a database runs an AFTER trigger, it performs extra work after a data change.
We want to know how this extra work grows as more data changes happen.
Analyze the time complexity of this AFTER trigger example.
CREATE TRIGGER update_log AFTER INSERT ON orders
FOR EACH ROW
BEGIN
INSERT INTO order_log(order_id, log_time) VALUES (NEW.id, NOW());
END;
This trigger adds a log entry every time a new order is inserted.
Look at what repeats when the trigger runs.
- Primary operation: Inserting one log record for each new order inserted.
- How many times: Once per inserted row in the orders table.
Each new order causes one log insert, so work grows with the number of inserted orders.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 log inserts |
| 100 | 100 log inserts |
| 1000 | 1000 log inserts |
Pattern observation: The work grows directly with the number of inserted rows.
Time Complexity: O(n)
This means the trigger's extra work increases in a straight line as more rows are inserted.
[X] Wrong: "The trigger runs only once no matter how many rows are inserted."
[OK] Correct: The trigger runs once for each inserted row, so the work adds up with more rows.
Understanding how triggers add work helps you explain database behavior clearly and shows you think about efficiency.
"What if the trigger was FOR EACH STATEMENT instead of FOR EACH ROW? How would the time complexity change?"
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
