Cách Database Migration giúp bạn "thoát cảnh" sửa database bằng tay

Ông đã bao giờ rơi vào cảnh code chạy phà phà ở máy mình, nhưng vừa đẩy lên server là nó "ngỏm" ngay lập tức vì quên thêm một cái cột vào bảng chưa? Hay tệ hơn là lúc làm nhóm, ông đồng nghiệp âm thầm đổi kiểu dữ liệu của cột từ chuỗi sang số mà không báo, khiến ông sửa lỗi cả buổi sáng? Nếu câu trả lời là "có", thì chào mừng ông đến với thế giới của những người chưa biết tới Database Migration.

Thay vì phải gõ lệnh SQL trực tiếp hay dùng chuột "vẽ" bảng trong mấy phần mềm quản lý dữ liệu, Migration giúp ông quản lý cấu trúc cơ sở dữ liệu như cách ông quản lý code bằng Git vậy. Mọi thay đổi đều được ghi lại, có thể quay ngược thời gian (rollback) và đặc biệt là cực kỳ an toàn.

Migration là cái gì mà nghe "kêu" thế?

Nói một cách dân dã nhất, Database Migration là các tệp tin lưu lại lịch sử thay đổi của cơ sở dữ liệu. Thay vì ông chạy lệnh ALTER TABLE bằng tay, ông sẽ viết một đoạn mã (thường là JavaScript hoặc TypeScript) để mô tả thay đổi đó. Khi cần áp dụng cho server hay máy của bạn bè, ông chỉ cần chạy một câu lệnh duy nhất là xong.

Cũng giống như cách GitHub Actions giúp ông tự động hóa việc đưa code lên server, Migration giúp ông đồng bộ hóa cấu trúc dữ liệu giữa tất cả các môi trường mà không lo sai sót con người. Ông sẽ không còn phải thức đêm để soi xem cột nào thiếu, cột nào dư nữa.

Tại sao không dùng SQL truyền thống cho nhanh?

Dùng SQL gõ trực tiếp thì nhanh thật đấy, nhưng nó chỉ nhanh lúc ông làm một mình thôi. Khi dự án lớn dần, ông sẽ thấy việc quản lý thủ công là một cơn ác mộng thực sự. Migration giải quyết được 3 vấn đề cốt lõi:

• Tính nhất quán: Đảm bảo máy local, máy test và máy production đều có cấu trúc bảng y hệt nhau.
• Làm việc nhóm: Khi ông tạo thêm bảng mới, ông chỉ cần commit file Migration đó lên Git. Bạn cùng nhóm pull về và chạy lệnh là xong, không cần phải hỏi nhau "ông vừa sửa gì ở database đấy?".
• An toàn: Mọi thay đổi đều được kiểm duyệt qua code. Nếu có lỡ tay xóa nhầm, ông vẫn còn lịch sử để khôi phục lại.

Thực tế, khi ông đã biết cách dùng PostgreSQL Index để tối ưu tốc độ, thì việc dùng Migration để quản lý các Index đó lại càng trở nên quan trọng hơn bao giờ hết. Ông sẽ biết chính xác Index đó được tạo ra từ khi nào và vì lý do gì.

Bắt đầu "tu hành" Migration từ đâu?

Nếu ông đang dùng Node.js, có rất nhiều công cụ xịn sò để bắt đầu. Phổ biến nhất hiện nay có thể kể đến Prisma, Drizzle ORM hoặc Knex.js. Cách hoạt động của chúng thường xoay quanh một quy trình đơn giản như sau:

// Ví dụ một file Migration đơn giản dùng để tạo bảng Users
exports.up = function(knex) {
  return knex.schema.createTable('users', table => {
    table.increments('id');
    table.string('name').notNullable();
    table.string('email').unique();
    table.timestamps(true, true);
  });
};

exports.down = function(knex) {
  return knex.schema.dropTable('users');
};

Đoạn mã trên chính là bảo hiểm cho database của ông. Hàm up là để tiến tới, còn hàm down là để rút lui nếu có biến. Để hiểu sâu hơn về cách các thư viện này tương tác với hệ thống, ông có thể tham khảo thêm tài liệu tại MDN Web Docs về Database cơ bản nhé.

Sau khi đã làm chủ được việc thay đổi cấu trúc dữ liệu, ông cũng đừng quên cài đặt PM2 để đảm bảo server của mình luôn chạy ổn định sau mỗi lần Migration thành công. Database mượt rồi, server cũng phải "bất tử" nữa thì mới đúng chuẩn backend chuyên nghiệp!

Nhưng mà, Migration mới chỉ là bước khởi đầu để bảo vệ dữ liệu thôi. Ông đã bao giờ nghĩ đến chuyện chuyện gì sẽ xảy ra nếu Migration chạy thành công nhưng dữ liệu cũ lại bị... mất sạch vì logic sai chưa?