D2 · Thiết kế theo cách truy vấn và tránh schema phình to

D2 · Middle

Đóng tủ bếp theo cách bạn nấu ăn hằng ngày, không theo catalogue của nhà hàng 5 sao. Tủ đẹp mà ngăn nào cũng trống chỉ tốn chỗ.

Cốt lõi

• Liệt kê các truy vấn chính (access patterns) trước: màn hình nào đọc gì, lọc theo gì, sắp xếp theo gì.
• Schema và index phục vụ các truy vấn đó; với NoSQL càng phải thiết kế theo truy vấn.
• YAGNI cho dữ liệu: không thêm bảng, cột "để sau này dùng"; khi cần thì migration thêm sau.
• Dữ liệu thừa tốn dung lượng, backup, index và làm truy vấn chậm.

Đánh đổi

Thiết kế quá sát truy vấn hiện tại có thể khó mở rộng; cân bằng bằng cách giữ lõi chuẩn hóa, thêm bảng đọc nhanh khi thật sự cần.

Trong thực tế

Schema do AI sinh ra hoặc chép từ hệ thống lớn: 40 bảng cho sản phẩm cần 8 bảng, thao tác đơn giản cũng phải JOIN 6 bảng.

Bug thường gặp

Bảng log/audit ghi mọi thứ mà không có chính sách xóa → chiếm phần lớn dung lượng DB, backup mất hàng giờ.

Tự hỏi lại

Khi nào nên dùng cột JSON thay vì tách bảng?