Trigger là gì trong DBMS? Cách hoạt động, các loại phổ biến và ứng dụng

Khi cần tự động ghi lại lịch sử thay đổi dữ liệu, hoặc đảm bảo một quy tắc nghiệp vụ luôn được thực thi mỗi khi dữ liệu trong bảng thay đổi, nhiều hệ quản trị cơ sở dữ liệu cung cấp một cơ chế gọi là trigger. Bài viết dưới đây giải thích trigger là gì, cách hoạt động và khi nào nên hoặc không nên dùng trigger.

Trigger là gì?

Trigger là cơ chế trong hệ quản trị cơ sở dữ liệu (DBMS) cho phép tự động thực thi một hành động khi một sự kiện đã xác định xảy ra, thường là khi có thao tác INSERT, UPDATE hoặc DELETE trên một bảng hoặc view. Cách triển khai cụ thể và loại sự kiện được hỗ trợ có thể khác nhau tùy từng hệ quản trị cơ sở dữ liệu, ví dụ SQL Server, MySQL hay PostgreSQL.

Ngoài trigger gắn với thao tác dữ liệu (DML trigger), một số hệ quản trị như SQL Server còn hỗ trợ thêm DDL trigger, kích hoạt khi có thay đổi cấu trúc cơ sở dữ liệu, và logon trigger, kích hoạt khi có phiên đăng nhập mới.

Trigger hoạt động như thế nào?

Về nguyên tắc chung, một trigger gồm ba thành phần: sự kiện kích hoạt (event), điều kiện tùy chọn (condition, nếu hệ quản trị hỗ trợ), và hành động sẽ thực thi (action).

Khi một câu lệnh INSERT, UPDATE hoặc DELETE được thực hiện trên bảng có gắn trigger, hệ quản trị cơ sở dữ liệu sẽ tự động kiểm tra xem có trigger nào tương ứng với sự kiện đó hay không. Nếu có, đoạn logic bên trong trigger sẽ được thực thi, có thể trước, sau hoặc thay cho câu lệnh gốc, tùy loại trigger được định nghĩa.

Các loại trigger phổ biến và sự khác nhau giữa các DBMS

Trigger thường được phân loại theo thời điểm kích hoạt so với sự kiện gốc: BEFORE, AFTER và INSTEAD OF. Tuy nhiên, không phải hệ quản trị cơ sở dữ liệu nào cũng hỗ trợ đầy đủ cả ba loại này, nên không nên xem đây là một chuẩn chung áp dụng giống nhau cho mọi DBMS.

- SQL Server hỗ trợ trigger loại AFTER (còn gọi là FOR) và INSTEAD OF, nhưng không có loại BEFORE. Để truy cập dữ liệu trước và sau khi thay đổi, SQL Server dùng hai bảng tạm gọi là inserted và deleted.

- MySQL hỗ trợ trigger loại BEFORE và AFTER, nhưng không hỗ trợ INSTEAD OF.

- PostgreSQL hỗ trợ đầy đủ cả ba loại BEFORE, AFTER và INSTEAD OF, trong đó INSTEAD OF chỉ áp dụng cho trigger gắn trên view.

Vì cú pháp và phạm vi hỗ trợ khác nhau giữa các hệ quản trị, khi học hoặc triển khai trigger, nên kiểm tra tài liệu chính thức của đúng DBMS đang sử dụng thay vì áp dụng kiến thức từ một hệ quản trị khác.

Trigger chạy theo từng hàng hay theo câu lệnh?

Bên cạnh thời điểm kích hoạt, trigger còn được phân loại theo phạm vi thực thi: row-level (theo từng hàng) hoặc statement-level (theo cả câu lệnh).

Trigger row-level chạy một lần cho mỗi hàng dữ liệu bị ảnh hưởng bởi câu lệnh. Trigger statement-level chỉ chạy đúng một lần cho toàn bộ câu lệnh, bất kể câu lệnh đó ảnh hưởng đến bao nhiêu hàng.

Khả năng hỗ trợ hai loại này cũng khác nhau giữa các DBMS. PostgreSQL hỗ trợ cả row-level lẫn statement-level. MySQL chỉ hỗ trợ trigger row-level. SQL Server về bản chất chỉ có trigger statement-level nhưng vẫn có thể truy cập toàn bộ các hàng bị ảnh hưởng thông qua hai bảng tạm inserted và deleted đã nhắc ở trên.

Ví dụ minh họa một trigger cơ bản

Dưới đây là ví dụ một trigger viết cho PostgreSQL, tự động ghi lại lịch sử mỗi khi giá sản phẩm trong bảng products được cập nhật, thay vì chỉ ghi đè giá trị cũ mà không lưu lại dấu vết:

CREATE OR REPLACE FUNCTION log_price_change()

RETURNS TRIGGER AS $$

BEGIN

  INSERT INTO audit_log (product_id, old_price, new_price, changed_at)

  VALUES (OLD.id, OLD.price, NEW.price, NOW());

  RETURN NEW;

END;

$$ LANGUAGE plpgsql;

CREATE TRIGGER after_products_update

AFTER UPDATE ON products

FOR EACH ROW

WHEN (OLD.price IS DISTINCT FROM NEW.price)

EXECUTE FUNCTION log_price_change();

Trong ví dụ này, mỗi khi giá sản phẩm thay đổi, trigger sẽ tự động thêm một dòng vào bảng audit_log, ghi lại giá cũ, giá mới và thời điểm thay đổi, mà không cần ứng dụng phải tự viết thêm logic này ở tầng code.

Trigger được dùng để làm gì?

Trigger thường được dùng trong các tình huống sau:

- Ghi log hoặc audit thay đổi dữ liệu: Tự động lưu lại lịch sử khi dữ liệu quan trọng bị thay đổi, như ví dụ ghi log giá sản phẩm ở trên.

- Đồng bộ dữ liệu phụ trợ: Tự động cập nhật một bảng liên quan khi bảng chính thay đổi, ví dụ cập nhật số lượng tồn kho tổng hợp khi có đơn hàng mới.

- Thực thi quy tắc nghiệp vụ phức tạp: Áp dụng cho các quy tắc không thể biểu diễn bằng constraint thông thường, ví dụ quy tắc phụ thuộc vào dữ liệu ở nhiều bảng khác nhau.

- Tự động hóa ở tầng cơ sở dữ liệu: Đảm bảo logic được thực thi nhất quán, bất kể ứng dụng nào đang thao tác với cơ sở dữ liệu.

Một lưu ý quan trọng: nếu một quy tắc có thể giải quyết bằng PRIMARY KEY, FOREIGN KEY, UNIQUE hoặc CHECK constraint, thường nên ưu tiên dùng constraint trước, thay vì viết trigger. Constraint được tối ưu sẵn cho các quy tắc toàn vẹn dữ liệu đơn giản, còn trigger phù hợp hơn cho các tình huống phức tạp mà constraint không xử lý được.

Ưu và nhược điểm của trigger

Ưu điểm: Trigger giúp tự động hóa các hành động ở tầng cơ sở dữ liệu mà không cần sửa code ứng dụng, đảm bảo logic được áp dụng nhất quán cho mọi nguồn ghi dữ liệu, kể cả khi có nhiều ứng dụng khác nhau cùng truy cập một cơ sở dữ liệu.

Nhược điểm: Vì logic của trigger nằm ẩn ở tầng cơ sở dữ liệu, việc debug khi có sự cố thường khó hơn so với logic viết trong code ứng dụng, do lập trình viên có thể không nhận ra trigger đang chạy ngầm phía sau một câu lệnh đơn giản. Trigger phức tạp hoặc nhiều trigger lồng nhau cũng có thể làm chậm hệ thống, đặc biệt với các thao tác ảnh hưởng đến số lượng lớn bản ghi.

Khi nào nên dùng trigger, khi nào không nên?

Nên cân nhắc dùng trigger khi cần audit thay đổi dữ liệu, đồng bộ dữ liệu giữa các bảng liên quan, hoặc thực thi một quy tắc nghiệp vụ mà constraint thông thường không đáp ứng được.

Nên hạn chế dùng trigger khi quy tắc có thể giải quyết đơn giản bằng constraint, khi logic nghiệp vụ quá lớn và phức tạp nên đặt ở tầng ứng dụng để dễ kiểm soát và debug hơn hoặc khi có nguy cơ tạo ra chuỗi trigger gọi lẫn nhau nhiều lớp, khiến hệ thống khó theo dõi và dễ phát sinh lỗi khó lường.

Câu hỏi thường gặp về trigger (FAQs)

Trigger có thay thế được việc kiểm tra dữ liệu ở tầng ứng dụng không? Không nên xem trigger là lớp thay thế hoàn toàn cho việc kiểm tra dữ liệu ở tầng ứng dụng. Trigger phù hợp hơn như một lớp bảo vệ bổ sung ở tầng cơ sở dữ liệu, đảm bảo quy tắc được áp dụng nhất quán bất kể ứng dụng nào đang ghi dữ liệu, chứ không phải để thay thế toàn bộ logic validate phía ứng dụng.

Một bảng có thể có nhiều trigger cùng lúc không? Có. Một bảng có thể có nhiều trigger khác nhau, ví dụ vừa có trigger AFTER INSERT để ghi log, vừa có trigger AFTER UPDATE để đồng bộ dữ liệu bảng khác. Tuy nhiên, càng có nhiều trigger trên cùng một bảng, việc theo dõi và debug khi có sự cố càng phức tạp hơn.

Trigger có làm chậm hệ thống không? Có thể, đặc biệt nếu trigger chứa logic phức tạp, chạy theo row-level trên các thao tác ảnh hưởng đến rất nhiều bản ghi, hoặc có nhiều trigger lồng gọi lẫn nhau. Vì vậy, trigger nên được thiết kế gọn nhẹ và chỉ dùng khi thực sự cần thiết, thay vì lạm dụng cho mọi loại logic.

Kết luận

Trigger là cơ chế mạnh trong DBMS, cho phép tự động thực thi hành động khi một sự kiện xảy ra trên bảng hoặc view, nhưng cách triển khai cụ thể (BEFORE, AFTER, INSTEAD OF, row-level hay statement-level) khác nhau tùy từng hệ quản trị cơ sở dữ liệu như SQL Server, MySQL hay PostgreSQL. 

Trigger phù hợp nhất cho các tình huống như ghi log, đồng bộ dữ liệu phụ trợ hoặc quy tắc nghiệp vụ phức tạp mà constraint thông thường không xử lý được nhưng nên tránh lạm dụng cho mọi loại logic, vì điều này có thể khiến hệ thống khó debug và ảnh hưởng đến hiệu suất về lâu dài.