Event Listener API: addEventListener() and removeEventListener()

ในระบบฐานข้อมูลขนาดใหญ่ การทำงานของข้อมูลไม่ได้จำกัดอยู่แค่การบันทึก (INSERT) หรือการเรียกดู (SELECT) เท่านั้น แต่บ่อยครั้งที่การกระทำหนึ่ง (เช่น การอัปเดตสถานะ) จะต้องส่งผลกระทบต่อตารางอื่น ๆ หรือต้องมีการบันทึก Log การเปลี่ยนแปลงอย่างอัตโนมัติ การจัดการการตอบสนองเหล่านี้อย่างมีประสิทธิภาพจึงเป็นหัวใจสำคัญของการออกแบบสถาปัตยกรรมฐานข้อมูลที่แข็งแกร่ง

Event Listener ใน PostgreSQL: การใช้ Triggers

ในบริบทของ PostgreSQL แนวคิดของ Event Listener ไม่ได้ใช้ JavaScript API แต่ถูกแทนที่ด้วยกลไกที่ทรงพลังที่เรียกว่า Triggers (ตัวกระตุ้น) Triggers คือโค้ดที่กำหนดให้ทำงานโดยอัตโนมัติ (Automatic Callback) เมื่อมีการดำเนินการ DML (Data Manipulation Language) เช่น INSERT, UPDATE, หรือ DELETE เกิดขึ้นกับตารางที่กำหนด

การสร้าง Trigger เปรียบเสมือนการ addEventListener() โดยเรากำลังลงทะเบียนฟังก์ชัน (Stored Procedure/Function) ให้ทำงานเมื่อเหตุการณ์ (Event) ของฐานข้อมูลเกิดขึ้น การจัดการ Trigger เหล่านี้อย่างเป็นระบบจึงสำคัญมาก

1. การลงทะเบียน Listener (CREATE TRIGGER)

เราใช้คำสั่ง CREATE TRIGGER เพื่อผูกฟังก์ชันที่เขียนไว้กับเหตุการณ์ที่ต้องการตรวจจับ ตัวอย่างเช่น หากเราต้องการให้ทุกครั้งที่มีการอัปเดตข้อมูลในตาราง products ต้องมีการบันทึก Log การเปลี่ยนแปลงลงในตาราง product_log:

SQL

-- 1. สร้างฟังก์ชันที่จะทำงานเมื่อเกิดเหตุการณ์ (The Callback Function) 
CREATE OR REPLACE FUNCTION log_product_change() 
RETURNS TRIGGER AS $$
BEGIN 
    INSERT INTO product_log (product_id, old_value, new_value, change_time) 
    VALUES (OLD.id, OLD.name, NEW.name, NOW());
    RETURN NEW; 
END;$$ LANGUAGE plpgsql;

-- 2. ลงทะเบียน Trigger เพื่อให้ฟังก์ชันทำงานเมื่อมีการ UPDATE 
CREATE TRIGGER product_update_trigger 
AFTER UPDATE ON products 
FOR EACH ROW 
EXECUTE FUNCTION log_product_change();

2. การยกเลิก Listener (DROP TRIGGER)

เช่นเดียวกับการจัดการหน่วยความจำใน JavaScript เราต้องสามารถล้าง Listener เมื่อมันไม่จำเป็นอีกต่อไป การใช้ DROP TRIGGER คือการยกเลิกการผูกเหตุการณ์ ทำให้ฐานข้อมูลไม่เรียกใช้โค้ดนั้น ๆ อีกต่อไป ซึ่งช่วยให้ระบบสะอาดและมีประสิทธิภาพสูงสุด:

SQL

DROP TRIGGER product_update_trigger ON products;

3. การสื่อสารแบบ Event Messaging (LISTEN/NOTIFY)

นอกจาก Triggers ที่ตอบสนองต่อการเปลี่ยนแปลงข้อมูลภายในแล้ว PostgreSQL ยังมีกลไก LISTEN และ NOTIFY สำหรับการส่งข้อความแบบ Asynchronous Event Messaging ระหว่างเซสชันต่าง ๆ ซึ่งเหมาะสำหรับการแจ้งเตือนสถานะโดยไม่จำเป็นต้องอัปเดตข้อมูลจริง

SQL

-- เซสชัน A (Publisher): ส่ง Event 
NOTIFY user_updates, 'user_id=123, status=active';

-- เซสชัน B (Subscriber): รอรับ Event 
LISTEN user_updates;

บทสรุป

การทำความเข้าใจ Triggers, CREATE TRIGGER, และ DROP TRIGGER ใน PostgreSQL ทำให้เราสามารถยกระดับการออกแบบฐานข้อมูลให้เป็นระบบที่ตอบสนอง (Reactive System) ได้อย่างสมบูรณ์ การจัดการ Event Listener เหล่านี้อย่างถูกหลักการ ไม่เพียงแต่ช่วยให้ข้อมูลมีความสอดคล้อง (Data Consistency) เท่านั้น แต่ยังช่วยให้ระบบมีเสถียรภาพและประสิทธิภาพสูงในระยะยาวด้วย