Database hay gặpCó — đây là trường hợp denormalize hợp lý (counter cache), nhưng phải trả lời được câu hỏi kèm theo: ai chịu trách nhiệm giữ số đó đúng.
Khi nào denormalize là đúng: tỷ lệ đọc/ghi rất lệch (đọc liên tục, comment thêm thưa), phép tính lặp lại y hệt ở nhiều nơi, và đã thử index/query tối ưu mà vẫn chậm. Đừng denormalize trước khi có số đo — chuẩn hoá vẫn là mặc định.
Ba cách giữ đồng bộ, độ chặt giảm dần:
1. Trigger trong database — cập nhật ngay trong cùng transaction với INSERT/DELETE comment, nên không bao giờ lệch. Đổi lại logic nghiệp vụ nằm trong database, khó test và dễ bị bỏ quên khi debug.
2. Cập nhật ở tầng ứng dụng, cùng transaction — dễ đọc hơn, nhưng chỉ đúng nếu mọi đường ghi đều đi qua đoạn code đó (script sửa tay, job import sẽ làm lệch).
3. Materialized view hoặc job tính lại định kỳ — tách hẳn khỏi đường ghi, chấp nhận số liệu trễ vài phút. Hợp với thống kê dashboard, không hợp với số hiển thị ngay sau thao tác của người dùng.
update posts set comment_count = comment_count + 1 where id = $1;Dù chọn cách nào cũng nên có job đối soát chạy định kỳ so comment_count với count(*) thật và ghi log chênh lệch — số đếm denormalize luôn có ngày lệch, phát hiện muộn thì khó lần ra nguyên nhân.
Lưu ý về tranh chấp: nhiều comment vào cùng một bài sẽ cùng UPDATE một dòng posts, tạo điểm nóng khoá. Bài viết bình thường thì không sao; nếu là bộ đếm cực nóng (lượt xem) thì tách bảng đếm riêng hoặc gộp tăng theo lô.