Constraints — DB là last line of defense, không trust app validation

TL;DR: Constraint là last line of defense cho integrity — không thể trust app-level validation vì khoảng giữa SELECT (check) và INSERT (write) không được lock, hai request đồng thời đều pass rồi đều ghi. 5 constraint chuẩn SQL: NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK — mỗi loại enforce một tầng integrity tại write time, atomic. FK quyết định cascading behavior (CASCADE/SET NULL/RESTRICT). Deferred constraint dời check tới cuối transaction (giải circular FK). Pitfall: app validate không thay được DB constraint; CHECK chỉ cho immutable per-row predicate.

App đã validate email duplicate trước khi insert. Chạy 6 tháng ổn. Black Friday traffic spike — 2 request cùng email pass validate trong cùng millisecond, cả hai insert thành công, cả hai row tồn tại trong database. Bug được phát hiện 3 tháng sau khi support team báo "user X có 2 account".

Đây là race condition kinh điển của app-level validation: khoảng thời gian giữa SELECT (check) và INSERT (write) không được bảo vệ. Constraint là last line of defense — không thể trust app validation cho integrity. Bài này map 5 loại constraint cốt lõi chuẩn SQL, generalized UNIQUE cho non-overlap, deferred constraint cho circular FK, cascading behavior, và 2 pitfall phổ biến. Tất cả là nguyên lý agnostic — đúng cho mọi RDBMS.

1. Analogy — Constraint là khoá vault

Hãy hình dung app validation là bảo vệ đứng trước cổng tòa nhà. Database constraint là khoá vault bên trong. Bảo vệ có thể nhầm — hai người cùng xuất trình giấy tờ đúng trong cùng lúc, cả hai đều được thả vào. Khoá vault không nhầm — chỉ một người mở được, người thứ hai nhận lỗi.

Race condition khi chỉ dựa vào app validation (hai request đồng thời cùng email):

sequenceDiagram
  participant R1 as Request 1
  participant R2 as Request 2
  participant DB as Database
  R1->>DB: SELECT email = '[email protected]'
  DB-->>R1: khong ton tai
  R2->>DB: SELECT email = '[email protected]'
  DB-->>R2: khong ton tai
  R1->>DB: INSERT '[email protected]'
  DB-->>R1: OK
  R2->>DB: INSERT '[email protected]'
  Note over DB: Khong co UNIQUE -> ca hai row ton tai (BUG)<br/>Co UNIQUE -> reject request 2 (SAFE)

2. 5 loại constraint cốt lõi

-- 1. NOT NULL: column khong duoc NULL
email VARCHAR(254) NOT NULL

-- 2. UNIQUE: khong duplicate value trong column
email VARCHAR(254) UNIQUE NOT NULL
-- Multi-column UNIQUE: cap (user_id, project_id) phai duy nhat
UNIQUE (user_id, project_id)

-- 3. PRIMARY KEY: NOT NULL + UNIQUE + tao index co thu tu mac dinh
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY
-- Composite PK cho junction table M:N
PRIMARY KEY (user_id, project_id)

-- 4. FOREIGN KEY: tham chieu den PK bang khac
project_id BIGINT NOT NULL REFERENCES projects(id)
-- Voi cascading (giai thich o Section 5)
project_id BIGINT NOT NULL REFERENCES projects(id) ON DELETE CASCADE

-- 5. CHECK: dieu kien bat buoc per-row
status VARCHAR(20) NOT NULL CHECK (status IN ('todo', 'doing', 'done'))
salary DECIMAL(12,2) NOT NULL CHECK (salary >= 0)

Quirks quan trọng (đúng với hầu hết RDBMS):

• Phần lớn engine tự tạo index có thứ tự cho mọi PRIMARY KEY và UNIQUE constraint — không cần tạo index riêng. (Cơ chế index có thứ tự được mổ ở Module 6 của khoá này.)
• FOREIGN KEY không tự tạo index trên cột FK ở nhiều engine. JOIN trên task.project_id mà thiếu index sẽ scan toàn bảng khi bảng lớn — cân nhắc tạo index thủ công cho cột FK hay JOIN.
• NOT NULL không cần index — NULL check xảy ra tại write time, không phải query time.

3. Generalized UNIQUE — chặn non-overlap, không chỉ bằng-nhau

UNIQUE chỉ check operator = (hai giá trị có bằng nhau không). Nhưng có ràng buộc cần chặn theo operator khác — điển hình là range non-overlap: booking phòng không được trùng khoảng thời gian.

Use case: booking phòng — không thể có 2 booking cùng phòng overlap thời gian.

-- Y tuong agnostic: rang buoc "khong hai row nao conflict theo dieu kien overlap"
-- Khong the dien dat bang UNIQUE thuong vi UNIQUE chi so sanh =

-- Cach phổ quat nhat: bang phu (helper) + constraint logic o app/transaction
--   Insert moi booking trong transaction:
--   1. Kiem tra khong co booking nao overlap (SELECT ... WHERE room_id = ? AND
--      khong (end <= new_start OR start >= new_end))
--   2. Neu khong co -> INSERT; neu co -> reject
--   De an toan race condition: lock row room hoac dung isolation level cao hon

Một số engine cung cấp ràng buộc loại trừ chuyên dụng (generalized UNIQUE check theo operator tuỳ ý, dựa trên index hỗ trợ range) — đây là tính năng dialect, cú pháp khác nhau theo engine. Khái niệm chung quan trọng hơn cú pháp: UNIQUE chỉ chặn giá trị bằng nhau chính xác, còn non-overlap cần một cơ chế mạnh hơn — hoặc ràng buộc loại trừ của engine, hoặc kiểm tra trong transaction với lock phù hợp.

4. Deferred constraint — giải quyết circular FK

Mặc định, RDBMS check constraint sau mỗi statement. Chuẩn SQL cho phép khai báo DEFERRABLE INITIALLY DEFERRED để dời check xuống cuối transaction (COMMIT).

Use case điển hình: circular FK — companies tham chiếu employees (CEO), employees tham chiếu companies. Insert bên nào trước cũng vi phạm FK.

CREATE TABLE companies (
  id     BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  ceo_id BIGINT REFERENCES employees(id) DEFERRABLE INITIALLY DEFERRED
);

CREATE TABLE employees (
  id         BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  company_id BIGINT NOT NULL REFERENCES companies(id) DEFERRABLE INITIALLY DEFERRED
);

BEGIN;
  -- Insert company truoc, ceo_id tro den employee chua ton tai
  -- OK vi constraint deferred den COMMIT
  INSERT INTO companies(id, ceo_id) VALUES (1, 1);

  -- Insert employee, company_id tro den company vua insert
  INSERT INTO employees(id, company_id) VALUES (1, 1);

  -- Ca hai check tai COMMIT -- luc nay ca hai row da co
COMMIT;

Nếu không có DEFERRABLE, INSERT đầu tiên sẽ báo lỗi FK ngay lập tức.

Deferred constraint hiếm dùng trong app thông thường — chủ yếu xuất hiện khi schema có circular FK hoặc khi migration tool cần tái cấu trúc dữ liệu trong một transaction (xem Bài 06 — Schema migration).

5. Cascading — ON DELETE / ON UPDATE behavior

Khi xoá/cập nhật row cha, FK quyết định hành vi với row con:

-- 4 option ON DELETE
ON DELETE NO ACTION   -- mac dinh: block delete neu co row con reference
ON DELETE RESTRICT    -- giong NO ACTION nhung check ngay, khong defer duoc
ON DELETE CASCADE     -- xoa row con theo khi xoa row cha
ON DELETE SET NULL    -- set column FK thanh NULL (column phai nullable)
ON DELETE SET DEFAULT -- set column FK ve gia tri DEFAULT

-- TaskFlow: comments la weak entity, ton tai phu thuoc task
CREATE TABLE comments (
  id      BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  task_id BIGINT NOT NULL REFERENCES tasks(id) ON DELETE CASCADE,
  user_id BIGINT       REFERENCES users(id)    ON DELETE SET NULL, -- nullable: bat buoc cho SET NULL
  body    VARCHAR(2000) NOT NULL
);
-- Xoa task -> tu dong xoa comment (weak entity, khong co y nghia doc lap)
-- Xoa user -> set comment.user_id NULL (preserve comment, lose author link)

Decision matrix:

NO ACTION và RESTRICT khác nhau chỉ khi dùng với deferred constraint: NO ACTION có thể defer đến cuối transaction, RESTRICT luôn check ngay.

6. Pitfall — app validation race condition

// SAI: race condition giua check va insert
const existing = await db.query(
  'SELECT id FROM users WHERE email = $1',
  [email]
);
if (existing.rows.length > 0) {
  throw new Error('Email already exists');
}
// Khoang trong o day: 2 request cung pass check, ca 2 tien den INSERT
await db.query('INSERT INTO users(email) VALUES ($1)', [email]);

Fix: tin tưởng DB UNIQUE constraint, catch lỗi unique violation:

try {
  await db.query('INSERT INTO users(email) VALUES ($1)', [email]);
} catch (e) {
  if (isUniqueViolation(e)) {  // moi engine bao loi unique violation theo cach rieng
    throw new Error('Email already exists');
  }
  throw e;  // re-throw loi khac
}

Cách nhận diện "lỗi unique violation" là dialect — chuẩn SQL định nghĩa SQLSTATE 23505 cho unique_violation, nhưng nhiều driver/engine còn phơi ra error code hoặc message riêng. Đóng gói việc nhận diện này vào một hàm (isUniqueViolation) để app không phụ thuộc cứng vào một engine.

7. Pitfall — CHECK không thay thế validation phức tạp

-- OK: check don gian, immutable, per-row
CHECK (age >= 0 AND age <= 150)
CHECK (status IN ('todo', 'doing', 'done'))
CHECK (start_at < end_at)

-- KHONG OK: check cross-row (phai dung trigger hoac app logic)
-- "User chi tao toi da 5 project" -- khong the dung CHECK
-- CHECK chi nhin thay row hien tai, khong nhin thay row khac

-- NGUY HIEM: check goi function khong immutable
CHECK (verified_at <= CURRENT_TIMESTAMP)
-- CURRENT_TIMESTAMP thay doi theo thoi gian -- nhieu engine reject CHECK nay
-- hoac neu accept, se fail random tuy thoi diem re-evaluate

8. Applied — TaskFlow constraint review

Đối chiếu TaskFlow schema (DDL đầy đủ ở Module 1 — tour TaskFlow schema) với constraint rationale:

-- users.email VARCHAR(254) UNIQUE NOT NULL
--   App validate unique? Race-prone. DB UNIQUE enforce: safe.
--   Bat loi unique violation de tra user-facing message.

-- project_members.role VARCHAR(20) NOT NULL CHECK (role IN ('owner','member','viewer'))
--   Enum-like validation bang CHECK.
--   Alternative la kieu ENUM/domain cua engine (dialect): type-safe hon,
--   nhung them gia tri thuong can ALTER schema phuc tap hon.
--   CHECK linh hoat hon cho value set co the thay doi.

-- tasks.project_id BIGINT NOT NULL REFERENCES projects(id)
--   Mandatory parent: task khong the ton tai khong co project.
--   Khong ON DELETE CASCADE -- xoa project KHONG tu xoa task.
--   Default (NO ACTION/RESTRICT): phai cleanup task truoc khi xoa project.
--   Design choice: preserve task history, require explicit cleanup.

-- tasks.assignee_id BIGINT REFERENCES users(id)
--   Nullable: task chua assign la hop le.
--   Khong ON DELETE CASCADE: xoa user KHONG xoa task.
--   Nen them ON DELETE SET NULL? Design choice -- task con gia tri
--   doc lap voi assignee, set NULL preserve task, lose assignment.

-- comments.task_id BIGINT NOT NULL REFERENCES tasks(id)
--   Comment la weak entity -- xoa task nen xoa comment (ON DELETE CASCADE).
--   Neu can preserve comment history (audit)? Thi RESTRICT + soft delete.
--   Them constraint nay an toan cho bang dang co du lieu: xem bai 06.

Thêm/sửa constraint trên bảng production đang có data cần migration cẩn thận — Bài 06 — Schema migration đi sâu về pattern an toàn (expand-contract, validate riêng).

9. Deep Dive — Constraints

10. Liên hệ các bài khác

• Bài 01 — Data types: type là tầng phòng thủ đầu (đúng loại dữ liệu), constraint là tầng tiếp theo (đúng quy tắc nghiệp vụ).
• Bài 03 — Normalization 1NF→3NF: FK và composite PK là công cụ chính khi tách bảng để chuẩn hoá.
• Bài 06 — Schema migration: thêm/sửa constraint (NOT NULL, FK, CHECK) trên bảng production cần pattern migration an toàn.
• Module 6 — Storage & indexing: vì sao PK/UNIQUE tự sinh index có thứ tự, và vì sao cột FK cần index riêng.
• Spring — bài 3.6 Validation: Bean Validation (@NotNull, @Email) là layer thứ nhất ở app, constraint DB là layer cuối — vì sao cần cả hai.

11. Tóm tắt

• 5 constraint core: NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK — mỗi loại enforce một tầng khác nhau của data integrity. Nguyên lý đúng ở mọi RDBMS.
• Hầu hết engine tự tạo index có thứ tự cho PK và UNIQUE. FK thường không tự có index — cân nhắc tạo thủ công cho cột FK hay JOIN (Module 6 của khoá này).
• Generalized UNIQUE (chặn non-overlap, không chỉ bằng-nhau): khái niệm phổ quát; một số engine có exclusion constraint declarative, còn lại kiểm tra trong transaction với lock phù hợp.
• Deferred constraint dời check xuống cuối transaction — dùng khi có circular FK. Hiếm gặp trong app thường, phổ biến trong migration.
• Cascading (CASCADE / SET NULL / RESTRICT / SET DEFAULT) là design decision: CASCADE cho weak entity, SET NULL để preserve child mất link, RESTRICT để force explicit cleanup.
• App validate email unique race-prone — trust DB UNIQUE constraint, bắt lỗi unique violation (SQLSTATE 23505; cách nhận diện cụ thể là dialect).
• CHECK chỉ cho immutable per-row predicate — không cross-row, không time-dependent function.
• Forward: Bài 03 — Normalization, Bài 06 — Schema migration, Module 7 của khoá này (transaction + retry on unique violation).

11. Tự kiểm tra

Bài tiếp theo: Normalization 1NF→3NF — refactor TaskFlow tags TEXT thành tags table