Khi ứng dụng còn nhỏ, nhiều nhóm có thói quen sửa trực tiếp bảng trong database: thêm cột bằng giao diện quản trị, đổi kiểu dữ liệu thủ công, xóa index khi thấy “chưa cần”. Cách này có thể nhanh trong vài ngày đầu, nhưng càng về sau càng dễ tạo ra tình trạng: máy lập trình viên một kiểu, môi trường staging một kiểu, production lại một kiểu khác. Database migration sinh ra để giải quyết vấn đề đó. Database migration là cách mô tả thay đổi cấu trúc dữ liệu bằng mã nguồn hoặc file có kiểm soát phiên bản. Thay vì nói “anh thêm giúp em cột phone vào bảng users”, ta tạo một migration rõ ràng: thêm cột nào, kiểu dữ liệu gì, có cho phép null không, có index không. Khi triển khai, hệ thống chạy các migration chưa được áp dụng để đưa database lên đúng trạng thái mong muốn. Ví dụ thực tế: ứng dụng thương mại điện tử cần thêm trạng thái giao hàng cho đơn hàng. Nếu sửa tay, có thể một môi trường dùng cột shipping_status, môi trường khác lại dùng delivery_status. Nếu dùng migration, cả nhóm thống nhất qua một thay đổi cụ thể: thêm cột shipping_status vào bảng orders, giá trị mặc định là pending, và có thể bổ sung index nếu thường xuyên lọc theo trạng thái. Một số nguyên tắc nên áp dụng: - Mỗi migration chỉ nên làm một nhóm thay đổi nhỏ, dễ hiểu. Đừng gom thêm cột, đổi tên bảng, xóa dữ liệu và tạo index phức tạp vào cùng một file nếu không cần thiết. - Luôn xem xét dữ liệu hiện có. Thêm cột NOT NULL vào bảng đã có hàng triệu bản ghi mà không có giá trị mặc định có thể gây lỗi hoặc khóa bảng lâu. - Cẩn thận với migration phá vỡ tương thích. Ví dụ đổi tên cột mà code cũ vẫn đang đọc cột cũ sẽ làm ứng dụng lỗi ngay khi triển khai lệch nhịp. - Có kế hoạch rollback, nhưng đừng ảo tưởng rollback lúc nào cũng an toàn. Xóa cột chứa dữ liệu thật thì không thể “quay lại” nếu chưa sao lưu hoặc chưa có chiến lược chuyển đổi. - Không sửa migration cũ đã chạy trên môi trường dùng chung hoặc production. Hãy tạo migration mới để điều chỉnh. Sửa lịch sử có thể khiến database của các thành viên trong nhóm lệch nhau. Một quy trình an toàn thường là: viết migration, chạy ở máy local, kiểm tra lại ứng dụng, chạy trên staging với dữ liệu gần giống thực tế, sau đó mới triển khai production. Với thay đổi lớn, nên tách thành nhiều bước. Chẳng hạn muốn đổi cột username thành login_name: trước tiên thêm cột mới, cập nhật code ghi cả hai cột, chuyển dữ liệu cũ sang cột mới, đổi code đọc cột mới, cuối cùng mới xóa cột cũ sau khi chắc chắn không còn dùng. Database migration không chỉ là chuyện kỹ thuật, mà còn là cách giao tiếp trong đội phát triển. Nhìn vào lịch sử migration, ta biết dữ liệu đã tiến hóa ra sao, vì sao có cột này, index kia xuất hiện từ lúc nào. Một dự án có migration rõ ràng sẽ dễ onboarding thành viên mới, dễ dựng môi trường thử nghiệm và giảm đáng kể những lỗi “máy em chạy được mà server thì không”. Lời khuyên ngắn gọn: hãy coi database schema là một phần của mã nguồn. Đã có Git cho code thì cũng nên có migration cho database. Khi thay đổi dữ liệu được viết ra rõ ràng, kiểm tra được và triển khai có quy trình, ứng dụng sẽ bền vững hơn rất nhiều.