Trả lời nhanh: Agent rất nhanh trong việc dựng bản nháp cấu trúc bảng, nhưng nó không biết nghiệp vụ của bạn nên hay bỏ sót ràng buộc và đặt chỉ mục theo thói quen chứ không theo truy vấn thật. Cách làm hiệu quả: mô tả nghiệp vụ bằng các câu hỏi mà hệ thống phải trả lời thay vì liệt kê bảng, rồi tự kiểm bốn chỗ: kiểu dữ liệu, ràng buộc, chỉ mục, và cách xóa dữ liệu liên quan. Bốn chỗ đó chiếm gần hết lỗi mà bản nháp máy sinh mắc phải.
Thiết kế database là quyết định khó sửa nhất trong một dự án: code viết lại được, cấu trúc bảng thì kéo theo dữ liệu thật và mọi thứ đã xây trên đó. Dùng agent ở khâu này tiết kiệm rất nhiều thời gian gõ, nhưng phần phán xét vẫn phải là của bạn. Bài này chỉ rõ ranh giới đó.
Mô tả nghiệp vụ cho đúng cách
Cách kém hiệu quả nhất là đưa cho agent một danh sách bảng bạn nghĩ ra. Khi đó nó chỉ chép lại ý tưởng của bạn kèm vài trường hiển nhiên.
Cách hiệu quả hơn là mô tả những câu hỏi mà hệ thống phải trả lời:
Hệ thống cần trả lời được:- Đơn hàng của một khách trong 30 ngày qua, sắp theo ngày- Doanh thu theo danh mục sản phẩm theo tháng- Sản phẩm nào sắp hết hàng ở kho nào- Lịch sử thay đổi trạng thái của một đơn Quy tắc nghiệp vụ:- Một đơn không bao giờ bị xóa, chỉ chuyển trạng thái hủy- Giá tại thời điểm đặt phải giữ nguyên dù giá sản phẩm đổi sau đóHai dòng quy tắc cuối là thứ agent không thể tự đoán, và chúng thay đổi hẳn thiết kế: quy tắc thứ hai buộc bạn lưu giá vào dòng chi tiết đơn thay vì chỉ tham chiếu tới sản phẩm. Bỏ sót nó là lỗi kinh điển, và nó chỉ lộ ra sau vài tháng khi báo cáo doanh thu cũ bỗng đổi số.
Bốn chỗ phải tự kiểm
Kiểu dữ liệu. Agent hay dùng kiểu số thực cho tiền, và đó là lỗi gây lệch số khi cộng dồn. Tiền phải dùng kiểu số thập phân chính xác. Tương tự, hãy kiểm cả cách lưu thời gian cho các hệ thống có nhiều múi giờ.
Ràng buộc. Khóa ngoại, ràng buộc duy nhất, ràng buộc kiểm tra giá trị. Bản nháp máy sinh thường có khóa ngoại nhưng thiếu ràng buộc nghiệp vụ, ví dụ số lượng phải lớn hơn không.
Chỉ mục. Đây là chỗ hay thừa và thiếu cùng lúc: thừa chỉ mục cho cột không ai lọc, thiếu chỉ mục cho đúng truy vấn bạn chạy hằng ngày. Hãy đối chiếu với danh sách câu hỏi ở phần trên.
Cách xóa dữ liệu liên quan. Xóa một khách hàng thì đơn hàng của họ ra sao. Agent hay chọn xóa theo dây chuyền vì đó là mặc định phổ biến, trong khi phần lớn hệ thống kinh doanh cần giữ lại đơn để đối soát.
Chỉ mục đặt theo truy vấn thật
Nguyên tắc: mỗi chỉ mục phải phục vụ một truy vấn cụ thể bạn biết là sẽ chạy nhiều. Chỉ mục không dùng tới vẫn tốn dung lượng và làm chậm mọi thao tác ghi.
-- Truy van thuc te: don hang cua mot khach, moi nhat truocSELECT * FROM don_hang WHERE khach_id = ? ORDER BY tao_luc DESC LIMIT 20; -- Chi muc phuc vu dung truy van doCREATE INDEX idx_don_khach_ngay ON don_hang (khach_id, tao_luc DESC);Chỉ mục nhiều cột phải đúng thứ tự: cột dùng để lọc trước, cột dùng để sắp xếp sau. Đảo thứ tự là chỉ mục gần như vô dụng cho truy vấn này, và đây là chi tiết agent hay làm sai.
Cách kiểm chứng chắc chắn nhất là đọc kế hoạch thực thi trên dữ liệu thật, theo bài đọc EXPLAIN. Đừng tin lời giải thích của mô hình về việc chỉ mục có được dùng hay không, hãy để database tự nói.
Rà migration trước khi chạy
Với dự án mới thì mọi thứ dễ. Rủi ro nằm ở việc đổi cấu trúc một bảng đã có nhiều dữ liệu:
- Thêm cột có giá trị mặc định trên bảng lớn có thể khóa bảng khá lâu tùy hệ quản trị và phiên bản.
- Đổi kiểu cột thường phải viết lại toàn bộ bảng.
- Thêm ràng buộc duy nhất sẽ thất bại nếu dữ liệu hiện có đã vi phạm, và bạn phải dọn dữ liệu trước.
Quy trình an toàn: sao lưu, đọc kỹ file SQL sinh ra, chạy thử trên bản sao có dữ liệu gần giống thật, rồi mới chạy trên hệ thống thật vào giờ ít khách. Với bảng rất lớn, tách thành nhiều bước nhỏ thay vì một lần đổi lớn.
Nếu bạn dùng lớp truy cập có công cụ sinh migration như trong bài về Prisma, nhớ rằng công cụ sinh ra SQL nhưng không biết bảng của bạn có bao nhiêu dòng, nên phần đánh giá rủi ro vẫn là việc của bạn.
Giao việc cho agent thế nào cho hiệu quả
Trình tự cho kết quả tốt:
- Bạn viết danh sách câu hỏi và quy tắc nghiệp vụ. Đây là phần chỉ bạn biết.
- Agent đề xuất cấu trúc bảng kèm giải thích vì sao tách bảng như vậy.
- Bạn soi bốn chỗ ở phần trên và hỏi lại những điểm lạ.
- Agent viết migration và dữ liệu mẫu để bạn thử truy vấn.
- Bạn chạy thử các truy vấn trong danh sách và đọc kế hoạch thực thi.
Bước cuối là bước nhiều người bỏ và cũng là bước có giá trị nhất: nó kiểm chứng thiết kế bằng chính công việc mà hệ thống sẽ phải làm, thay vì bằng cảm giác rằng cấu trúc trông hợp lý.
Ghi lại các quyết định thiết kế kèm lý do vào tài liệu trong repo, theo bài về memory. Sáu tháng sau, chính bạn sẽ cần đọc lại để biết vì sao bảng kia được tách làm hai.
Bốn chỗ phải tự kiểm, không giao hết cho công cụ
| Chỗ | Vì sao phải tự kiểm | Hậu quả nếu sai |
|---|---|---|
| Kiểu dữ liệu cho tiền | Công cụ hay chọn kiểu số thực | Sai số khi cộng dồn, lệch sổ sách |
| Kiểu dữ liệu cho ngày giờ và múi giờ | Hay bỏ qua phần múi giờ | Lệch 7 tiếng với bản ghi tạo lúc nửa đêm |
| Ràng buộc khóa ngoại và ràng buộc duy nhất | Hay bị bỏ qua để mã chạy được | Dữ liệu mồ côi và bản ghi trùng |
| Chỉ mục | Công cụ đặt theo cảm tính | Truy vấn chậm khi dữ liệu tăng |
Hai dòng đầu là hai lỗi gây hậu quả lâu dài nhất và khó phát hiện nhất, vì hệ thống vẫn chạy bình thường, chỉ là số liệu sai dần. Với dữ liệu tiền và ngày giờ, luôn tự kiểm.
Mô tả kém và mô tả tốt, đặt cạnh nhau
# Mo ta KEM: "thiet ke bang cho he thong ban hang"# -> ra mot luoc do chung chung khong dung nghiep vu cua ban # Mo ta TOT: neu ro cac quy tac nghiep vu that# "Mot don hang thuoc ve mot khach hang.# Mot don co nhieu dong hang. Moi dong ghi lai gia TAI THOI DIEM MUA,# vi gia san pham co the doi sau do.# Tien luu bang so nguyen don vi dong.# Thoi diem luu theo gio chuan quoc te, hien thi theo gio Viet Nam.# Ma don hang phai duy nhat va khong tai su dung." # Quy tac ghi gia tai thoi diem mua la vi du dien hinh:# cong cu khong tu biet, va bo qua no la sai sot ke toanĐặt chỉ mục theo truy vấn thật
- Đừng đặt chỉ mục trước khi biết truy vấn nào hay chạy. Mỗi chỉ mục làm chậm lệnh ghi và tốn dung lượng.
- Đặt cho cột hay xuất hiện trong điều kiện lọc và cột nối bảng.
- Với điều kiện nhiều cột, một chỉ mục ghép đúng thứ tự tốt hơn nhiều chỉ mục rời.
- Sau vài tháng chạy thật, rà lại chỉ mục nào không ai dùng và xóa đi. Xem bài về chỉ mục cơ sở dữ liệu.
Rà tệp thay đổi cấu trúc trước khi chạy
Đọc tệp thay đổi cấu trúc trước khi chạy, đặc biệt tìm ba thứ: lệnh xóa cột, lệnh xóa bảng, và lệnh đổi kiểu dữ liệu. Ba lệnh này có thể mất dữ liệu và không quay lui được. Với bảng nhiều dữ liệu, chạy thử trên bản sao trước và bấm giờ, vì một số thay đổi khóa bảng rất lâu.
Câu hỏi thường gặp
Agent thiết kế database có đáng tin không?
Bản nháp thì rất hữu ích và tiết kiệm nhiều thời gian. Nhưng nó không biết quy tắc nghiệp vụ của bạn, nên phần ràng buộc và cách xử lý dữ liệu liên quan phải do bạn quyết. Hãy soi kiểu dữ liệu, ràng buộc, chỉ mục và cách xóa.
Nên tách bảng tới mức nào?
Tách khi các phần dữ liệu có vòng đời khác nhau hoặc kích thước chênh lệch lớn. Đừng tách chỉ vì lý thuyết chuẩn hóa: mỗi lần tách là thêm một lần nối bảng ở mọi truy vấn sau này.
Bao nhiêu chỉ mục là đủ?
Đủ để phục vụ các truy vấn chạy thường xuyên, không hơn. Mỗi chỉ mục làm chậm thao tác ghi và tốn dung lượng. Cách chắc chắn là liệt kê truy vấn thật rồi đọc kế hoạch thực thi để xem chỉ mục có được dùng không.
Cấu hình máy chủ nào cho database?
RAM quan trọng nhất vì nó quyết định bao nhiêu dữ liệu nằm trong bộ nhớ đệm. Sau đó tới tốc độ ổ đĩa, vì mọi thứ vượt quá bộ nhớ đệm đều phải xuống đĩa. CPU thường là yếu tố ít quan trọng nhất với database vừa.