Denormalization tradeoff — khi nào break 3NF có chủ đích

Dashboard TaskFlow cần hiển thị 200 task mỗi trang, mỗi task kèm tên project và số comment. Query chuẩn 3NF join 8 bảng, chạy 800ms. Người dùng rời trang sau 2 giây. Sau khi denormalize tasks.project_name (copy từ projects.name) và tasks.comment_count (precomputed), cùng query chạy 50ms — nhanh hơn 16 lần. Nhưng đêm hôm đó, một project đổi tên. Mọi task của project đó vẫn hiển thị tên cũ — cho đến khi sync chạy.

Đây là tradeoff cốt lõi của denormalization: đánh đổi write cost (phải sync nhiều nơi) để lấy read speed (không cần JOIN, không cần aggregate). Bài này map 3 pattern denormalize phổ biến, cơ chế sync, và decision matrix để biết khi nào nên — và khi nào không nên — break 3NF.

1. Analogy — Cache local vs nguồn chính

Denormalization giống cache: bạn lưu một bản sao dữ liệu gần hơn với người dùng, để đọc nhanh hơn. Nguồn chính (bảng gốc, normalized) vẫn tồn tại — bản sao chỉ để tăng tốc read. Nhưng mỗi khi nguồn chính thay đổi, bản sao phải được sync — đây là write overhead.

2. Read vs write amplification — tradeoff cơ bản

Decision criteria:

• Read-heavy (analytics dashboard, public-facing): denormalize
• Write-heavy OLTP: normalize
• Real-time consistency bắt buộc (financial, audit): normalize
• Eventual consistency chấp nhận được: denormalize tier

Nguyên tắc thực chiến: bắt đầu normalize hoàn toàn, đo đạc query chậm bằng EXPLAIN ANALYZE, rồi mới denormalize có mục tiêu. Premature denormalization = tech debt không có measurement để justify.

3. Pattern 1 — Cached column (denormalized FK label)

Use case: dashboard cần hiển thị label của parent entity (project name, user display name) kèm mỗi row child — thay vì JOIN mỗi request.

-- Normalize: phai JOIN moi query
SELECT t.id, t.title, p.name AS project_name
FROM tasks t
INNER JOIN projects p ON t.project_id = p.id;

-- Denormalize: them cached column
ALTER TABLE tasks ADD COLUMN project_name TEXT;
UPDATE tasks
SET project_name = (SELECT name FROM projects WHERE id = tasks.project_id);

-- Read: khong JOIN
SELECT id, title, project_name FROM tasks;

Ba cơ chế sync khi projects.name thay đổi:

-- A. Trigger tren projects: automatic, atomic
CREATE OR REPLACE FUNCTION sync_project_name() RETURNS TRIGGER AS $$
BEGIN
  UPDATE tasks
  SET project_name = NEW.name
  WHERE project_id = NEW.id;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_sync_project_name
  AFTER UPDATE OF name ON projects
  FOR EACH ROW EXECUTE FUNCTION sync_project_name();

-- B. App-level: explicit, de debug, de miss
BEGIN;
  UPDATE projects SET name = $1 WHERE id = $2;
  UPDATE tasks SET project_name = $1 WHERE project_id = $2;
COMMIT;
-- Nho them: bat ky noi nao update projects.name deu phai sync

-- C. CDC (Change Data Capture): Debezium, Kafka Connect
-- Doc change log cua PG (WAL) -> push event -> consumer update tasks
-- Eventual consistency: co lag, khong atomic voi update goc
-- Scale tot nhat nhung infra phuc tap nhat

Tradeoff mỗi cơ chế sync:

4. Pattern 2 — Counter table (precomputed COUNT)

Use case: profile page hiển thị "user X có 42 task" — không cần COUNT(*) mỗi request.

ALTER TABLE users ADD COLUMN task_count INT NOT NULL DEFAULT 0;

-- Backfill: tinh lai tu dau
UPDATE users u
SET task_count = (SELECT COUNT(*) FROM tasks WHERE assignee_id = u.id);

Trigger sync khi tasks thay đổi:

CREATE OR REPLACE FUNCTION update_user_task_count() RETURNS TRIGGER AS $$
BEGIN
  IF TG_OP = 'INSERT' THEN
    UPDATE users SET task_count = task_count + 1 WHERE id = NEW.assignee_id;
  ELSIF TG_OP = 'DELETE' THEN
    UPDATE users SET task_count = task_count - 1 WHERE id = OLD.assignee_id;
  ELSIF TG_OP = 'UPDATE' AND OLD.assignee_id IS DISTINCT FROM NEW.assignee_id THEN
    -- assignee thay doi: giam counter assignee cu, tang counter assignee moi
    UPDATE users SET task_count = task_count - 1 WHERE id = OLD.assignee_id;
    UPDATE users SET task_count = task_count + 1 WHERE id = NEW.assignee_id;
  END IF;
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_user_task_count
  AFTER INSERT OR UPDATE OR DELETE ON tasks
  FOR EACH ROW EXECUTE FUNCTION update_user_task_count();

Counter drift là rủi ro thực tế: bug trong trigger, bulk import không qua trigger, hoặc direct SQL update bypass trigger — counter lệch so với thực tế. Cần periodic reconciliation:

-- Reconcile: recompute counter tu source of truth
UPDATE users u
SET task_count = (SELECT COUNT(*) FROM tasks WHERE assignee_id = u.id);
-- Chay via cron job (hang dem hoac hang tuan tuy muc do chap nhan drift)

Real-world reference: Wikipedia denormalize page view counter, Twitter denormalize follower count, Reddit denormalize karma score — tất cả đều dùng periodic reconciliation để correct drift.

5. Pattern 3 — Materialized view (precomputed aggregate)

Cho complex aggregate cần nhiều bảng và tính toán phức tạp — analytics dashboard chấp nhận staleness.

-- "Moi project: tong task, so task done, completion %"
CREATE MATERIALIZED VIEW mv_project_stats AS
SELECT
  p.id          AS project_id,
  p.name,
  COUNT(*)      AS total,
  COUNT(*) FILTER (WHERE t.status = 'done')    AS done,
  ROUND(
    COUNT(*) FILTER (WHERE t.status = 'done') * 100.0
    / NULLIF(COUNT(*), 0),
    2
  )             AS completion_pct
FROM projects p
LEFT JOIN tasks t ON t.project_id = p.id
GROUP BY p.id, p.name;

-- Index bat buoc de dung REFRESH CONCURRENTLY
CREATE UNIQUE INDEX ON mv_project_stats(project_id);

-- Read: instant, khong JOIN, khong aggregate per request
SELECT * FROM mv_project_stats WHERE project_id = $1;

Refresh schedule:

-- CONCURRENTLY: khong block read trong khi refresh (can unique index)
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_project_stats;

-- Khong CONCURRENTLY: block read, nhung khong can unique index
REFRESH MATERIALIZED VIEW mv_project_stats;

-- Chay dinh ky via pg_cron extension (Module 11 cua khoa nay deep dive):
-- SELECT cron.schedule('refresh-project-stats', '*/5 * * * *',
--   'REFRESH MATERIALIZED VIEW CONCURRENTLY mv_project_stats');

Tradeoff materialized view:

• Freshness: stale theo refresh interval (5 phút, 1 giờ, 1 ngày)
• Cost refresh: linear với data size, không incremental (PG native)
• Storage: tăng theo size aggregate
• CONCURRENTLY: cần unique index, chạy lâu hơn nhưng không block read

Use case phù hợp: analytics dashboard chấp nhận 1 giờ lag, OLAP report. Không phù hợp: OLTP cần data real-time (dùng normalize + index thay thế).

Forward: Module 11 của khoá này đi sâu về materialized view production — pg_cron schedule, monitoring refresh lag, incremental refresh pattern với logical replication.

6. Pitfall — denormalize không có sync

-- BUG: denormalize nhung quen setup sync
ALTER TABLE tasks ADD COLUMN project_name TEXT;

-- Backfill 1 lan duy nhat
UPDATE tasks
SET project_name = (SELECT name FROM projects WHERE id = tasks.project_id);

-- 6 thang sau: project "Alpha" doi ten thanh "Alpha v2"
UPDATE projects SET name = 'Alpha v2' WHERE id = 5;
-- tasks.project_name van la 'Alpha' voi moi task thuoc project 5
-- Dashboard show 'Alpha' trong 6 thang -> silent wrong data

-- Fix options:
-- 1. Them trigger sync ngay khi alter (truoc khi deploy)
-- 2. Chap nhan stale va document ro trong code + README
-- 3. Periodic reconciliation script + monitoring alert

7. Decision matrix — khi nào denormalize

                  Read frequency
                  Thấp         Cao
Write    Thấp  |  Normalize  | Cached column (label ít thay đổi)
freq     Cao   |  Normalize  | Counter table + Materialized view

Rules of thumb:

• Read nhiều hơn write khoảng 100 lần và query chậm có bằng chứng đo được? Cân nhắc denormalize.
• Real-time consistency bắt buộc (financial, security, audit)? Normalize, không exception.
• Parent label thay đổi hiếm (project name, category name)? Cached column với trigger OK.
• Event-driven counter (page view, comment count, task count)? Counter table với trigger + reconciliation.
• Aggregate phức tạp nhiều bảng, dashboard analytics chấp nhận lag? Materialized view.
• Chưa đo được query chậm? Normalize trước, đo sau, denormalize khi có evidence.

8. Applied — TaskFlow denormalization candidates

Best practice áp dụng ngay: bắt đầu với schema fully normalized từ Module 4 bài 3 của khoá này. Khi dashboard TaskFlow chậm, chạy EXPLAIN ANALYZE (Module 7 của khoá này), tìm sequential scan + expensive hash join, rồi chọn đúng pattern denormalize cho bottleneck đó.

9. Deep Dive — Denormalization

10. Tóm tắt

• Denormalize = đánh đổi write cost (sync overhead) để lấy read speed (no JOIN, no aggregate).
• 3 pattern: cached column (FK label copy), counter table (precomputed COUNT), materialized view (precomputed aggregate).
• Sync mechanism: trigger (atomic, ẩn), app-level (explicit, dễ miss), CDC (scale tốt, eventual consistency).
• Counter table cần periodic reconciliation tránh drift sau bug hoặc bulk operation bypass trigger.
• Materialized view dùng REFRESH CONCURRENTLY (cần unique index) để không block read trong khi refresh.
• Decision: normalize trước, denormalize có measurement — premature denormalize là tech debt không justify được.
• Forward: Module 5 của khoá này (index trên denormalized column để query nhanh hơn), Module 7 của khoá này (EXPLAIN ANALYZE để tìm bottleneck trước khi denormalize), Module 11 của khoá này (materialized view production với pg_cron).

11. Tự kiểm tra

Bài tiếp theo: Surrogate vs natural key — UUID vs serial vs UUIDv7