What if deleting one record could magically clean up everything related to it without you lifting a finger?
Why DELETE trigger in SQL? - Purpose & Use Cases
Imagine you have a big list of customers in a spreadsheet. When you delete a customer, you also need to remove all their orders and related info manually from other sheets. This takes a lot of time and you might forget some places.
Manually deleting related data is slow and risky. You can easily miss some records, causing errors or broken links. It's hard to keep everything clean and consistent by hand.
A DELETE trigger automatically runs code when you delete a record. It can remove or update related data instantly, keeping your database clean and consistent without extra work.
DELETE FROM orders WHERE customer_id = 123; DELETE FROM customers WHERE id = 123;
DELETE FROM customers WHERE id = 123; -- DELETE trigger handles orders automaticallyDELETE triggers let your database handle complex cleanup tasks automatically, so you never miss important steps.
In an online store, when a customer account is deleted, a DELETE trigger can automatically remove all their shopping carts and wishlists, keeping the system tidy.
Manual deletion of related data is error-prone and slow.
DELETE triggers automate cleanup tasks on record removal.
This keeps your database consistent and saves time.
Practice
DELETE trigger in a database?Solution
Step 1: Understand what triggers do
Triggers run automatically in response to certain database events like insert, update, or delete.Step 2: Focus on DELETE triggers
A DELETE trigger specifically runs when rows are deleted, allowing automatic actions during that event.Final Answer:
To automatically run code when rows are deleted from a table -> Option CQuick Check:
DELETE trigger = runs on row deletion [OK]
- Confusing DELETE triggers with INSERT triggers
- Thinking DELETE triggers prevent deletion by default
- Assuming DELETE triggers update rows instead
Employees?Solution
Step 1: Identify correct trigger timing syntax
The syntax for a BEFORE DELETE trigger includes 'BEFORE DELETE ON TableName'.Step 2: Check full syntax correctness
CREATE TRIGGER before_delete_employee BEFORE DELETE ON Employees FOR EACH ROW BEGIN --code END; correctly uses 'CREATE TRIGGER name BEFORE DELETE ON Employees FOR EACH ROW BEGIN ... END;'. Others misuse order or keywords.Final Answer:
CREATE TRIGGER before_delete_employee BEFORE DELETE ON Employees FOR EACH ROW BEGIN --code END; -> Option DQuick Check:
BEFORE DELETE ON Table = correct syntax [OK]
- Placing BEFORE DELETE after ON table
- Omitting FOR EACH ROW clause
- Using DELETE ON instead of BEFORE DELETE ON
id = 2 from Orders?
CREATE TRIGGER log_delete AFTER DELETE ON Orders FOR EACH ROW BEGIN INSERT INTO DeletedOrdersLog(order_id, deleted_at) VALUES (OLD.id, CURRENT_TIMESTAMP); END; -- Initial Orders table: -- id | product -- 1 | Book -- 2 | Pen -- 3 | Notebook -- DeletedOrdersLog is initially empty.
Solution
Step 1: Understand AFTER DELETE trigger behavior
The trigger runs after a row is deleted from Orders, so OLD.id refers to the deleted row's id.Step 2: Analyze trigger action
The trigger inserts a new row into DeletedOrdersLog with order_id = OLD.id (2) and current timestamp.Final Answer:
A new row with order_id = 2 is inserted into DeletedOrdersLog -> Option AQuick Check:
AFTER DELETE inserts log row with OLD.id [OK]
- Thinking OLD.id is not accessible in DELETE triggers
- Assuming trigger restores deleted rows
- Believing no action happens after delete
Users table if the user is an admin:
CREATE TRIGGER prevent_admin_delete BEFORE DELETE ON Users
FOR EACH ROW
BEGIN
IF OLD.role = 'admin' THEN
SIGNAL SQLSTATE '45000' MESSAGE_TEXT = 'Cannot delete admin user';
END IF;
END;
What is the main issue if this trigger does not prevent admin deletions?Solution
Step 1: Check trigger timing and row context
BEFORE DELETE and FOR EACH ROW are correctly used to check OLD.role before deletion.Step 2: Verify SIGNAL syntax
In standard SQL, SIGNAL syntax requires correct SQLSTATE and message format. If syntax is wrong, error won't raise and deletion proceeds.Final Answer:
The SIGNAL statement syntax is incorrect -> Option AQuick Check:
SIGNAL syntax error prevents trigger from blocking delete [OK]
- Using AFTER DELETE instead of BEFORE DELETE
- Checking NEW instead of OLD in DELETE triggers
- Omitting FOR EACH ROW clause
Products table that archives deleted rows into an ArchivedProducts table, but only if the product price is above 100. Which trigger definition correctly implements this logic?Solution
Step 1: Choose correct timing and row reference
AFTER DELETE triggers run after deletion; OLD refers to deleted row data. BEFORE DELETE can also work but OLD is preferred after deletion.Step 2: Check condition and insert logic
Condition must check OLD.price > 100. Insert must use OLD column values to archive deleted row data.Step 3: Validate options
CREATE TRIGGER archive_expensive_product AFTER DELETE ON Products FOR EACH ROW BEGIN IF OLD.price > 100 THEN INSERT INTO ArchivedProducts (id, price) VALUES (OLD.id, OLD.price); END IF; END; uses AFTER DELETE, OLD.price, and inserts OLD.id, OLD.price correctly. Others use NEW or wrong timing.Final Answer:
CREATE TRIGGER archive_expensive_product AFTER DELETE ON Products FOR EACH ROW BEGIN IF OLD.price > 100 THEN INSERT INTO ArchivedProducts (id, price) VALUES (OLD.id, OLD.price); END IF; END; -> Option BQuick Check:
AFTER DELETE + OLD.price condition + insert OLD columns = correct [OK]
- Using NEW instead of OLD in DELETE triggers
- Placing condition on NEW.price which is invalid
- Using BEFORE DELETE but referencing OLD incorrectly
Ready to prove it?
Pass the test and this pattern moves unknown
