Login

Migration trong Laravel: quản lý cấu trúc cơ sở dữ liệu như quản lý code

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Bạn sửa cấu trúc bảng trên máy mình rồi quên báo đồng đội, thế là mỗi người một kiểu database và ứng dụng lỗi lung tung. Migration giải quyết đúng vấn đề này: mô tả thay đổi cơ sở dữ liệu bằng code, có phiên bản, có thể chạy lại và hoàn tác.

Migration là gì?

Mỗi migration là một file PHP chứa hai phần: up (áp dụng thay đổi) và down (hoàn tác). Laravel ghi nhận migration nào đã chạy trong bảng migrations, nên khi bạn chạy lệnh trên một máy khác, chỉ những migration mới mới được thực thi. Nhờ vậy cấu trúc database đi cùng Git, như mọi phần code khác.

Tạo bảng đầu tiên

php artisan make:migration create_orders_table
public function up(): void{    Schema::create('orders', function (Blueprint $table) {        $table->id();        $table->foreignId('user_id')->constrained()->cascadeOnDelete();        $table->string('code', 20)->unique();        $table->decimal('total', 12, 2)->default(0);        $table->string('status', 20)->default('pending')->index();        $table->timestamps();    });}public function down(): void{    Schema::dropIfExists('orders');}

Chạy bằng php artisan migrate. Để xem trạng thái, dùng php artisan migrate:status. Để hoàn tác lô vừa chạy, dùng php artisan migrate:rollback.

Thay đổi bảng đã có

Quy tắc vàng: đừng sửa migration đã chạy trên môi trường dùng chung. Hãy tạo migration mới để thay đổi.

php artisan make:migration add_note_to_orders_table --table=orders
public function up(): void{    Schema::table('orders', function (Blueprint $table) {        $table->text('note')->nullable()->after('status');    });}public function down(): void{    Schema::table('orders', function (Blueprint $table) {        $table->dropColumn('note');    });}

Lưu ý khi thêm cột vào bảng đã có dữ liệu: cột mới nên cho phép nullable hoặc có giá trị mặc định, nếu không câu lệnh sẽ lỗi hoặc ghi dữ liệu không như ý.

Thực hành tốt

  • Luôn viết down đúng: dù nhiều nhóm hiếm khi rollback ở production, down chuẩn giúp bạn thử nghiệm thoải mái ở môi trường phát triển.
  • Dùng khóa ngoại và chỉ mục: khóa ngoại bảo vệ tính toàn vẹn dữ liệu; index trên các cột hay lọc, sắp xếp giúp truy vấn nhanh hơn.
  • Tách thay đổi cấu trúc và di chuyển dữ liệu: mỗi migration làm một việc rõ ràng, dễ đọc lại sau này.
  • Cẩn thận với bảng lớn: đổi cấu trúc bảng hàng triệu dòng có thể khóa bảng trong thời gian dài, hãy lên kế hoạch và thử trên bản sao trước.
  • Đừng dùng model trong migration: model thay đổi theo thời gian, còn migration thì cố định; hãy dùng DB::table() để tránh vỡ về sau.

Seeder và dữ liệu mẫu

Migration lo cấu trúc, còn seeder lo dữ liệu mẫu hoặc dữ liệu khởi tạo. Kết hợp lệnh php artisan migrate:fresh --seed khi phát triển giúp bạn dựng lại cơ sở dữ liệu sạch chỉ trong vài giây. Tuyệt đối không chạy migrate:fresh trên production vì nó xóa toàn bộ bảng.

Triển khai an toàn

Trên môi trường thật, dùng php artisan migrate --force trong quy trình deploy, và luôn sao lưu trước khi chạy migration quan trọng. Với những thay đổi phá vỡ tương thích, như đổi tên hoặc xóa cột đang dùng, hãy làm theo nhiều bước: thêm cột mới, cho code ghi vào cả hai, chuyển dữ liệu, rồi mới xóa cột cũ ở lần phát hành sau.

Làm việc nhóm với migration

Khi nhiều người cùng thêm migration, tên file có timestamp giúp sắp xếp thứ tự chạy. Xung đột thường xảy ra khi hai người cùng sửa một bảng; cách tránh là trao đổi sớm, và luôn kéo code mới nhất trước khi tạo migration. Nếu hai migration thêm cột khác nhau vào cùng bảng thì không sao, nhưng nếu cùng đổi một cột thì cần thống nhất.

Với dự án đã có nhiều năm lịch sử, hàng trăm file migration có thể làm việc dựng database mới chậm. Laravel cho phép nén chúng thành một file schema bằng lệnh php artisan schema:dump, sau đó các migration cũ có thể được dọn đi, còn máy mới vẫn dựng nhanh từ file schema.

Kiểm tra trước khi chạy ở production

Trước khi triển khai, hãy dùng php artisan migrate --pretend để xem trước các câu SQL sẽ chạy mà không thực thi thật. Đây là cách rẻ tiền để phát hiện câu lệnh nguy hiểm, ví dụ một lệnh ALTER thay đổi kiểu cột có thể làm mất dữ liệu. Kết hợp với bản sao lưu gần nhất, bạn sẽ yên tâm hơn nhiều mỗi lần phát hành.

Một lời khuyên cuối

Hãy xem tên file migration như một dòng lịch sử mà đồng đội sẽ đọc sau này. Đặt tên mô tả đúng hành động như add_status_to_orders_table thay vì update_table, và thêm chú thích ngắn khi có quyết định khó hiểu. Chi phí chỉ vài giây, nhưng giúp ích rất nhiều khi cần truy vết vì sao một cột tồn tại.

Kết luận

Migration biến cấu trúc database thành thứ có thể review, versioning và tự động hóa. Hãy tập thói quen mọi thay đổi database đều đi qua migration, bạn sẽ tránh được kiểu lỗi "máy tôi chạy được" rất khó chịu trong làm việc nhóm.

Muốn học bài bản và có lộ trình rõ ràng? Bạn có thể xem các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment