Theory
Riya के marks किसने बदले?
Monday: Riya का DBMS score 78 पढ़ता है। Thursday: यह 88 पढ़ता है। Exam cell ResultDesk से पूछता है: किसने बदला, कब, और किससे?
आपकी tables current value store करती हैं, इसके पीछे की story नहीं। आप marks छूने वाले हर program से एक log भी लिखने को कह सकते हैं... और जिस दिन कोई भूल जाए, audit trail में एक छेद हो जाता है।
बेहतर: database को ख़ुद react करना सिखाइए। "जब भी कोई marks update करे, पुरानी और नई value automatically record कीजिए।" यह standing instruction एक trigger है।
Theory
Register के ऊपर CCTV
एक clerk हर correction note करने का promise कर सकता है, पर promises fail होते हैं। Register के ऊपर एक CCTV camera नहीं होता: यह हर बदलाव record करता है, चाहे कोई भी करे, यहाँ तक कि रात 2 बजे भी।
एक trigger एक table के लिए CCTV है: table पर ही parked, एक चुने event (INSERT, UPDATE, DELETE) की watching करते हुए, और अपनी recording routine automatically चलाते हुए। कोई application इसे भूल नहीं सकता, क्योंकि किसी application से पूछा ही नहीं जाता।
Theory
Trigger, formally
एक trigger एक named database object है जो SQL रखता है जो एक specified table पर एक specified event होने पर automatically execute होता है।
तीन choices इसे define करती हैं:
- Event: INSERT, UPDATE या DELETE।
- Timing: बदलाव से BEFORE (validate कीजिए, बुरा data block कीजिए) या इसके AFTER (log कीजिए, cascade कीजिए)।
- Body: BEGIN और END के बीच का SQL।
Body के अंदर दो magic row-aliases रहते हैं: NEW (आती हुई values) और OLD (replace हो रही values)। INSERT में सिर्फ़ NEW है; DELETE में सिर्फ़ OLD; UPDATE में दोनों।
Practical
Audit CCTV, installed
CREATE TABLE marks_log (
roll INTEGER,
subject TEXT,
old_score INTEGER,
new_score INTEGER,
changed_on TEXT
);
CREATE TRIGGER log_marks_change
AFTER UPDATE ON marks
BEGIN
INSERT INTO marks_log
VALUES (OLD.roll, OLD.subject, OLD.score, NEW.score,
datetime('now'));
END;
-- now ANY update writes its own evidence:
UPDATE marks SET score = 88 WHERE roll = 101 AND subject = 'DBMS';
-- marks_log gains: 101, DBMS, 78, 88, 2026-07-04 ...
-- a BEFORE trigger can BLOCK bad data:
CREATE TRIGGER stop_bad_scores
BEFORE UPDATE ON marks
WHEN NEW.score > 100 OR NEW.score < 0
BEGIN
SELECT RAISE(ABORT, 'score must be 0..100');
END;
This example runs in Gri-Learn on the web, where you can edit it and see the output.
Think first
BEFORE या AFTER? प्रति job चुनिए
दो jobs: (1) results week के दौरान students table पर कोई भी DELETE मना करना; (2) जब भी एक नया mark INSERT हो, subject का running total update करना। tap करने से पहले: हर एक के लिए timing (BEFORE/AFTER) और event चुनिए, और बताइए हर body NEW/OLD में से किसे इस्तेमाल कर सकता है।
Show the answer
(1) students पर BEFORE DELETE: validation/blocking बदलाव से पहले होता है, body OLD इस्तेमाल करती है (मरने वाली row) और RAISE(ABORT, ...) मना करने के लिए।
(2) marks पर AFTER INSERT: row सुरक्षित रूप से मौजूद होने पर react कीजिए, body NEW इस्तेमाल करती है (आती हुई values) total में NEW.score जोड़ने के लिए।
Rule of thumb: BEFORE guard करता है, AFTER react करता है। और NEW/OLD की availability event को follow करती है: INSERT NEW लाता है, DELETE OLD छोड़ता है, UPDATE दोनों ढोता है।
Quiz
एक exam आपसे SQLite में एक trigger temporarily disable करने को कहता है। सही जवाब क्या है?
- SQLite में कोई DISABLE/ENABLE TRIGGER नहीं है: आप trigger DROP करते हैं और बाद में re-CREATE करते हैं
- ALTER TRIGGER log_marks_change DISABLE;
- DISABLE TRIGGER log_marks_change;
- Table के schema में trigger_enabled = 0 set कीजिए
Show the answer
SQLite में कोई DISABLE/ENABLE TRIGGER नहीं है: आप trigger DROP करते हैं और बाद में re-CREATE करते हैं
बड़े engines (SQL Server, Oracle) DISABLE/ENABLE TRIGGER offer करते हैं; SQLite नहीं करता, और इसमें कोई ALTER TRIGGER भी नहीं है। Honest SQLite workflow है DROP TRIGGER name; और ज़रूरत पड़ने पर इसे दोबारा CREATE कीजिए (CREATE statement saved रखिए)। यह engine-difference बिल्कुल इसलिए है कि syllabus 'disable and enable trigger' list करता है: expected answer SQLite की limitation जानना है, syntax invent करना नहीं।
Watch out
तीन trigger traps
DISABLE syntax invent करना: SQLite में जवाब drop-and-recreate है, full stop।
Event के लिए ग़लत alias: एक INSERT trigger के अंदर OLD, या DELETE के अंदर NEW, एक error है: alias को उससे match कीजिए जो event के पास असल में है।
BEFORE से logging: एक BEFORE UPDATE log एक ऐसा बदलाव record कर सकता है जो फिर fail हो जाए और कभी न हो। Audit logs AFTER triggers में रहते हैं, एक बार बदलाव असली होने पर।
Theory
आपके चारों तरफ़ Triggers, और उनकी cost
Bank statements (हर transaction logged), inventory systems (हर sale पर stock decremented), आपके college का fee system defaulters को flag करता: trigger territory। एक professional caution जो quote करने लायक़ है: triggers invisibly चलते हैं, तो कई triggers वाली एक table के बारे में reason करना मुश्किल हो जाता है। इन्हें cross-cutting guarantees (audit, integrity) के लिए इस्तेमाल कीजिए, business logic के लिए नहीं जिसे एक program owns करना चाहिए। आप sqlite_master table (type = 'trigger') के ज़रिए एक database के triggers list कर सकते हैं।
Summary
Key takeaways
- एक trigger = stored SQL जिसे database एक table के INSERT/UPDATE/DELETE पर automatically चलाता है।
- Timing: BEFORE guard करता है (validate, RAISE(ABORT)), AFTER react करता है (log, cascade)।
- NEW = आती हुई values, OLD = replaced values; INSERT में सिर्फ़ NEW, DELETE में सिर्फ़ OLD, UPDATE में दोनों।
- CREATE TRIGGER name AFTER UPDATE ON table BEGIN ... END; DROP TRIGGER name; इसे हटाता है।
- SQLite में कोई DISABLE/ENABLE या ALTER TRIGGER नहीं है: इसके बजाय drop और re-create (exam favourite)।
- Classic use: marks audit log जिसे कोई भूलक्कड़ application skip नहीं कर सकता।
- Memory hook: register के ऊपर CCTV।