وقتی یک پروژه Laravel را شروع می‌کنیم، یکی از اولین نیازهای ما ساختاردهی دیتابیس است. باید مشخص کنیم چه جدول‌هایی داریم، هر جدول چه ستون‌هایی دارد، ارتباط بین جدول‌ها چگونه است و در آینده چطور می‌توانیم ساختار دیتابیس را تغییر دهیم.
در پروژه‌های کوچک ممکن است بتوانیم این کارها را مستقیماً از طریق ابزارهایی مانند phpMyAdmin یا نرم‌افزارهای مدیریت دیتابیس انجام دهیم؛ اما در پروژه‌های حرفه‌ای این روش مشکلات زیادی ایجاد می‌کند.
Laravel برای حل این مشکل قابلیتی به نام Migration در اختیار توسعه‌دهنده قرار می‌دهد.
Migration به ما اجازه می‌دهد ساختار دیتابیس را به صورت کد تعریف کنیم و تغییرات مربوط به جداول و ستون‌ها را مانند بخشی از کد پروژه مدیریت کنیم.
در این مقاله یاد می‌گیریم:
- Migration در Laravel چیست؟
- چرا باید از Migration استفاده کنیم؟
- Migrationها کجا قرار می‌گیرند؟
- چگونه Migration بسازیم؟
- چگونه جدول ایجاد کنیم؟
- چگونه ستون‌های مختلف را تعریف کنیم؟
- چگونه کلید خارجی ایجاد کنیم؟
- چگونه Index ایجاد کنیم؟
- چگونه یک جدول موجود را تغییر دهیم؟
- چگونه Migration را Rollback کنیم؟
- تفاوت
migrate:freshوmigrate:refreshچیست؟ - در محیط Production چگونه Migration اجرا کنیم؟
- چه اشتباهاتی هنگام کار با Migration نباید انجام دهیم؟
Migration در Laravel چیست؟
Migration در Laravel سیستمی برای تعریف و مدیریت ساختار دیتابیس به صورت کد است.
به جای اینکه برای ساخت یک جدول وارد phpMyAdmin شویم و به صورت دستی جدول، ستون‌ها و Indexها را ایجاد کنیم، می‌توانیم ساختار آن را در یک فایل PHP تعریف کنیم.
برای مثال، فرض کنید می‌خواهیم جدول products را ایجاد کنیم:
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->decimal('price', 12, 2);
$table->timestamps();
});
Laravel با اجرای این Migration، ساختار مورد نظر را در دیتابیس ایجاد می‌کند.
بنابراین Migration را می‌توان نوعی نسخه‌بندی ساختار دیتابیس در نظر گرفت.
چرا Migration در Laravel اهمیت دارد؟
فرض کنید روی یک پروژه به صورت تیمی کار می‌کنید.
شما روی سیستم خودتان یک جدول جدید ایجاد کرده‌اید، اما برنامه‌نویس دیگری که به پروژه اضافه شده است، هنوز آن جدول را ندارد.
اگر ساختار دیتابیس فقط به صورت دستی مدیریت شود، هماهنگ نگه داشتن محیط‌های مختلف بسیار دشوار می‌شود.
Migration این مشکل را حل می‌کند.
برای مثال:
Developer 1
↓
Migration
↓
Git
↓
Developer 2
↓
Same Database Structure
با این روش، ساختار دیتابیس نیز همراه با کد پروژه قابل انتقال و نسخه‌بندی است.
مهم‌ترین مزایای Migration
| مزیت | توضیح |
|---|---|
| نسخه‌بندی دیتابیس | تغییرات دیتابیس مانند کد پروژه ثبت می‌شوند |
| همکاری تیمی | همه اعضای تیم می‌توانند ساختار یکسانی داشته باشند |
| Rollback | امکان بازگرداندن تغییرات وجود دارد |
| انتقال پروژه | ساختار دیتابیس به راحتی روی سرور جدید ایجاد می‌شود |
| کاهش خطای انسانی | نیاز به ساخت دستی جدول‌ها کمتر می‌شود |
| مستندسازی | تاریخچه تغییرات دیتابیس مشخص است |
# Migrationها کجا قرار دارند؟
Migrationهای Laravel در مسیر زیر قرار می‌گیرند:
database/migrations
اگر این پوشه را باز کنید، معمولاً فایل‌هایی شبیه موارد زیر می‌بینید:
database/
└── migrations/
├── 2026_01_01_000000_create_users_table.php
├── 2026_01_01_000001_create_cache_table.php
└── 2026_01_01_000002_create_jobs_table.php
نام فایل Migration معمولاً شامل یک Timestamp است.
این Timestamp به Laravel کمک می‌کند ترتیب اجرای Migrationها را مشخص کند.
# چگونه یک Migration جدید بسازیم؟
برای ساخت Migration از Artisan استفاده می‌کنیم.
مثلاً برای ساخت جدول محصولات:
php artisan make:migration create_products_table
Laravel یک فایل جدید در پوشه:
database/migrations
ایجاد می‌کند.
نام فایل چیزی شبیه این خواهد بود:
2026_10_02_120000_create_products_table.php
عدد ابتدای فایل توسط Laravel برای مشخص کردن ترتیب Migration استفاده می‌شود.
# ساختار یک Migration در Laravel
یک Migration معمولاً دو متد اصلی دارد:
up()
و:
down()
مثلاً:
return new class extends Migration
{
public function up(): void
{
//
}
public function down(): void
{
//
}
};
متد up چیست؟
کد داخل up() زمانی اجرا می‌شود که Migration را اعمال می‌کنیم.
مثلاً:
public function up(): void
{
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->timestamps();
});
}
این کد جدول products را ایجاد می‌کند.
متد down چیست؟
متد down() مشخص می‌کند هنگام Rollback چه اتفاقی بیفتد.
مثلاً:
public function down(): void
{
Schema::dropIfExists('products');
}
یعنی اگر Migration برگشت داده شد، جدول products حذف شود.
به زبان ساده:
up()
↓
اعمال تغییر
down()
↓
برگرداندن تغییر
# ساخت اولین جدول با Migration
بیایید یک جدول کامل‌تر برای محصولات ایجاد کنیم.
ابتدا:
php artisan make:migration create_products_table
سپس فایل ایجادشده را باز کرده و می‌توانیم چیزی شبیه این بنویسیم:
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
public function up(): void
{
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->text('description')->nullable();
$table->decimal('price', 12, 2);
$table->boolean('is_active')->default(true);
$table->timestamps();
});
}
public function down(): void
{
Schema::dropIfExists('products');
}
};
حالا Migration را اجرا می‌کنیم:
php artisan migrate
اگر اتصال دیتابیس صحیح باشد، جدول products ایجاد خواهد شد.
# Schema در Laravel چیست؟
در Migrationها زیاد با چیزی به نام Schema مواجه می‌شویم.
Schema ابزار Laravel برای مدیریت ساختار دیتابیس است.
مثلاً:
Schema::create(...)
برای ساخت جدول استفاده می‌شود.
یا:
Schema::table(...)
برای تغییر جدول موجود استفاده می‌شود.
یا:
Schema::dropIfExists(...)
برای حذف جدول استفاده می‌شود.
# Blueprint چیست؟
در کدی مانند:
Schema::create('products', function (Blueprint $table) {
متغیر $table یک شیء از کلاس Blueprint است.
Blueprint به ما اجازه می‌دهد ساختار جدول را تعریف کنیم.
مثلاً:
$table->id();
$table->string('name');
$table->integer('stock');
$table->boolean('is_active');
هر کدام از این دستورات یک بخش از ساختار جدول را مشخص می‌کنند.
# انواع ستون‌ها در Migration
Laravel برای تعریف انواع مختلف ستون‌ها متدهای متنوعی دارد.
ستون ID
رایج‌ترین روش:
$table->id();
این دستور یک ستون Primary Key برای جدول ایجاد می‌کند.
ستون String
برای متن‌های کوتاه:
$table->string('name');
مثلاً:
Product Name
Username
Email
Title
ستون Text
برای متن‌های طولانی‌تر:
$table->text('description');
ستون Integer
برای اعداد صحیح:
$table->integer('stock');
مثلاً:
10
25
100
500
ستون Boolean
برای مقادیر درست و غلط:
$table->boolean('is_active');
مثلاً:
true
false
ستون Decimal
برای مقادیر اعشاری، مخصوصاً قیمت:
$table->decimal('price', 12, 2);
در این مثال:
12
تعداد کل ارقام را مشخص می‌کند و:
2
تعداد ارقام بعد از اعشار است.
برای سیستم‌های مالی باید نوع داده را با توجه به نیاز پروژه و دیتابیس انتخاب کرد و معمولاً نباید مبلغ پول را با float ذخیره کرد.
ستون Date
برای تاریخ:
$table->date('published_at');
ستون DateTime
برای تاریخ و ساعت:
$table->dateTime('published_at');
ستون JSON
برای ذخیره داده‌های ساختاریافته JSON:
$table->json('options');
استفاده از JSON باید با توجه به نوع دیتابیس و نیاز واقعی پروژه انجام شود؛ JSON جایگزین طراحی صحیح رابطه‌های دیتابیس نیست.
# timestamps چیست؟
یکی از دستورات بسیار پرکاربرد:
$table->timestamps();
است.
این دستور معمولاً دو ستون ایجاد می‌کند:
created_at
updated_at
ستون created_at زمان ایجاد رکورد و updated_at زمان آخرین تغییر آن را نگهداری می‌کند.
این ستون‌ها در بسیاری از مدل‌های Eloquent کاربرد دارند.
# nullable در Migration
فرض کنید توضیحات محصول اختیاری است.
می‌توانیم بنویسیم:
$table->text('description')->nullable();
در این حالت مقدار NULL برای این ستون مجاز خواهد بود.
مثلاً:
$table->string('phone')->nullable();
یعنی شماره تلفن می‌تواند خالی باشد.
تفاوت nullable با رشته خالی
این دو مفهوم یکی نیستند:
NULL
و:
''
اولی به معنی نبودن مقدار است و دومی یک رشته خالی است.
# default در Migration
اگر بخواهیم مقدار پیش‌فرض تعیین کنیم:
$table->boolean('is_active')->default(true);
اگر هنگام ایجاد رکورد مقدار is_active ارسال نشود، مقدار پیش‌فرض true استفاده خواهد شد.
مثال دیگر:
$table->integer('stock')->default(0);
# ساخت Unique Column
اگر یک مقدار باید در جدول یکتا باشد، می‌توانیم از unique() استفاده کنیم.
مثلاً ایمیل:
$table->string('email')->unique();
در این حالت دیتابیس از ثبت مقدار تکراری برای این ستون جلوگیری می‌کند.
این موضوع با Validation در Laravel متفاوت است.
Validation می‌تواند قبل از ثبت داده خطا را به کاربر نشان دهد، اما Unique Constraint در سطح دیتابیس نیز یک لایه مهم برای جلوگیری از داده تکراری ایجاد می‌کند.
# Index در Migration
Index برای بهبود جست‌وجو و برخی عملیات روی دیتابیس استفاده می‌شود.
مثلاً:
$table->index('status');
یا:
$table->index(['user_id', 'status']);
البته Index رایگان نیست؛ Indexهای زیاد می‌توانند حجم دیتابیس و هزینه عملیات نوشتن را افزایش دهند. بنابراین باید بر اساس Queryهای واقعی و نیاز پروژه طراحی شوند.
# کلید خارجی در Laravel
یکی از مهم‌ترین کاربردهای Migration تعریف ارتباط بین جدول‌ها است.
فرض کنید جدول products متعلق به یک کاربر است و می‌خواهیم user_id داشته باشیم.
یک روش مدرن و خوانا:
$table->foreignId('user_id')->constrained();
Laravel بر اساس نام user_id معمولاً رابطه با جدول users را تشخیص می‌دهد.
می‌توانیم رفتار حذف را نیز مشخص کنیم:
$table->foreignId('user_id')
->constrained()
->cascadeOnDelete();
در این حالت حذف رکورد والد می‌تواند باعث حذف رکوردهای وابسته شود.
مثال
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->foreignId('user_id')
->constrained()
->cascadeOnDelete();
$table->string('name');
$table->decimal('price', 12, 2);
$table->timestamps();
});
ساختار منطقی به این شکل خواهد بود:
users
│
│ 1
│
└───────< products
*
یعنی یک کاربر می‌تواند چند محصول داشته باشد.
# ساخت Foreign Key به صورت دستی
گاهی نام جدول یا ستون با Convention معمول Laravel متفاوت است.
در چنین شرایطی می‌توانیم Foreign Key را صریح‌تر تعریف کنیم:
$table->unsignedBigInteger('owner_id');
$table->foreign('owner_id')
->references('id')
->on('users');
این روش زمانی کاربرد دارد که ساختار نام‌گذاری استاندارد نباشد.
# تغییر جدول موجود با Schema::table
فرض کنید جدول products قبلاً ساخته شده است و حالا می‌خواهیم ستون sku را به آن اضافه کنیم.
ابتدا Migration جدید می‌سازیم:
php artisan make:migration add_sku_to_products_table
سپس:
public function up(): void
{
Schema::table('products', function (Blueprint $table) {
$table->string('sku')->nullable()->unique();
});
}
و برای Rollback:
public function down(): void
{
Schema::table('products', function (Blueprint $table) {
$table->dropUnique(['sku']);
$table->dropColumn('sku');
});
}
نکته مهم این است که معمولاً نباید Migration قبلی را که در محیط‌های مختلف اجرا شده، برای تغییر جدید دستکاری کنیم. بهتر است برای هر تغییر جدید یک Migration جدید ایجاد کنیم.
# تغییر نام ستون
برای تغییر نام ستون می‌توان از:
$table->renameColumn('old_name', 'new_name');
استفاده کرد.
مثلاً:
Schema::table('products', function (Blueprint $table) {
$table->renameColumn('name', 'title');
});
در پروژه واقعی، قبل از تغییر ستون‌های موجود باید اثر این تغییر روی Modelها، Queryها، Validationها، APIها و کدهای دیگر بررسی شود.
# حذف ستون
برای حذف یک ستون:
$table->dropColumn('description');
مثلاً:
Schema::table('products', function (Blueprint $table) {
$table->dropColumn('description');
});
حذف ستون در Production یک عملیات حساس است و بهتر است قبل از آن Backup مناسب داشته باشید.
# اجرای Migration
برای اجرای Migrationهای اجرا نشده:
php artisan migrate
Laravel وضعیت Migrationهای قبلی را بررسی می‌کند و فقط Migrationهای اجرا نشده را اجرا می‌کند.
# مشاهده وضعیت Migrationها
برای مشاهده وضعیت Migrationها:
php artisan migrate:status
این دستور کمک می‌کند بفهمیم کدام Migrationها اجرا شده‌اند و کدام‌ها هنوز اجرا نشده‌اند.
مثلاً خروجی می‌تواند چیزی شبیه این باشد:
Migration Ran
2026_01_01_000000_create_users_table Yes
2026_01_01_000001_create_products_table Yes
2026_01_01_000002_create_orders_table No
# Rollback در Laravel چیست؟
Rollback یعنی برگرداندن Migrationهای اجراشده.
برای Rollback آخرین Batch:
php artisan migrate:rollback
فرض کنید چند Migration را اجرا کرده‌ایم و حالا می‌خواهیم آخرین مجموعه تغییرات را برگردانیم.
Laravel از متد down() مربوط به Migrationها استفاده می‌کند.
# migrate:reset چیست؟
دستور:
php artisan migrate:reset
Migrationها را به عقب برمی‌گرداند.
این دستور با rollback تفاوت دارد و برای برگرداندن مجموعه Migrationها استفاده می‌شود.
# migrate:refresh چیست؟
دستور:
php artisan migrate:refresh
Migrationها را Rollback کرده و دوباره اجرا می‌کند.
این قابلیت در محیط توسعه بسیار کاربردی است.
در صورت نیاز می‌توان Seeder را نیز همراه آن اجرا کرد:
php artisan migrate:refresh --seed
# migrate:fresh چیست؟
دستور:
php artisan migrate:fresh
تمام جدول‌های دیتابیس را حذف کرده و Migrationها را از ابتدا اجرا می‌کند.
مثلاً:
php artisan migrate:fresh
یا همراه با Seeder:
php artisan migrate:fresh --seed
تفاوت refresh و fresh
| دستور | عملکرد |
|---|---|
migrate | Migrationهای اجرا نشده را اجرا می‌کند |
migrate:rollback | آخرین Batch را برمی‌گرداند |
migrate:reset | Migrationها را به عقب برمی‌گرداند |
migrate:refresh | Rollback و اجرای مجدد Migrationها |
migrate:fresh | حذف جداول و ساخت مجدد همه جداول |
نکته بسیار مهم
دستور:
php artisan migrate:fresh
برای Production خطرناک است، چون جدول‌های دیتابیس را حذف می‌کند.
این دستور عمدتاً برای محیط Development و Testing مناسب است.
# Migration و Seeder چه تفاوتی دارند؟
Migration و Seeder معمولاً کنار هم استفاده می‌شوند، اما وظایف متفاوتی دارند.
Migration ساختار دیتابیس را ایجاد و تغییر می‌دهد.
Seeder داده اولیه را وارد دیتابیس می‌کند.
مثلاً Migration:
Schema::create('categories', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->timestamps();
});
جدول را ایجاد می‌کند.
اما Seeder می‌تواند داده‌هایی مانند:
Laravel
PHP
WordPress
n8n
را وارد جدول کند.
بنابراین:
Migration
↓
ساختار دیتابیس
Seeder
↓
داده اولیه
مقاله بعدی این مجموعه به صورت اختصاصی درباره Seeder خواهد بود.
# Migration و Eloquent چه ارتباطی دارند؟
Migration ساختار جدول را تعریف می‌کند، در حالی که Eloquent برای کار کردن با داده‌های آن جدول استفاده می‌شود.
مثلاً Migration:
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->decimal('price', 12, 2);
$table->timestamps();
});
و Model:
class Product extends Model
{
protected $fillable = [
'name',
'price',
];
}
در این معماری:
Migration
↓
Database Structure
↓
Eloquent Model
↓
Application
این تفکیک یکی از مفاهیم مهم در توسعه پروژه‌های Laravel است.
# ترتیب اجرای Migrationها چگونه مشخص می‌شود؟
Laravel از Timestamp موجود در نام فایل Migration برای تعیین ترتیب استفاده می‌کند.
مثلاً:
2026_10_01_100000_create_users_table.php
2026_10_01_100001_create_products_table.php
2026_10_01_100002_create_orders_table.php
در این مثال ابتدا users، سپس products و بعد orders اجرا می‌شود.
این موضوع زمانی اهمیت زیادی پیدا می‌کند که یک Migration به جدول دیگری وابسته باشد.
مثلاً اگر products دارای:
$table->foreignId('user_id')->constrained();
باشد، جدول users باید در زمان مناسب وجود داشته باشد.
# یک مثال واقعی‌تر؛ طراحی چند جدول
فرض کنیم می‌خواهیم یک فروشگاه ساده Laravel ایجاد کنیم.
جداول اصلی:
users
categories
products
orders
order_items
ساختار کلی:
users
│
├──── products
│
└──── orders
│
└──── order_items
│
└──── products
categories
│
└──── products
Migration مربوط به دسته‌بندی:
Schema::create('categories', function (Blueprint $table) {
$table->id();
$table->string('name');
$table->timestamps();
});
Migration مربوط به محصولات:
Schema::create('products', function (Blueprint $table) {
$table->id();
$table->foreignId('category_id')
->constrained()
->cascadeOnDelete();
$table->string('name');
$table->decimal('price', 12, 2);
$table->unsignedInteger('stock')->default(0);
$table->boolean('is_active')->default(true);
$table->timestamps();
});
با این ساختار، هر محصول می‌تواند به یک دسته‌بندی متصل باشد.
بعداً در بخش Relationship و Eloquent، این ارتباط را در Modelها نیز تعریف خواهیم کرد.
# Migration در محیط Production
در محیط Production باید با Migrationها با دقت بیشتری رفتار کرد.
برای اجرای Migration در Production معمولاً از:
php artisan migrate --force
استفاده می‌شود.
گزینه --force برای تأیید اجرای عملیات در محیط Production استفاده می‌شود.
اما قبل از اجرای Migrationهای مهم بهتر است:
- از دیتابیس Backup داشته باشید.
- Migration را روی محیط Staging تست کنید.
- تغییرات مخرب را بررسی کنید.
- اثر تغییر روی کدهای فعلی را بررسی کنید.
- در صورت امکان Migration را به چند مرحله امن تقسیم کنید.
# چرا نباید Migrationهای قدیمی را بی‌دلیل ویرایش کنیم؟
فرض کنید این Migration قبلاً روی Production اجرا شده است:
2026_09_01_100000_create_products_table.php
حالا یک ماه بعد متوجه می‌شویم که ستون جدیدی نیاز داریم.
روش بهتر این نیست که فایل قبلی را تغییر دهیم.
بهتر است Migration جدید بسازیم:
php artisan make:migration add_sku_to_products_table
و تغییر جدید را در آن قرار دهیم.
چرا؟
چون ممکن است Migration قبلی قبلاً روی دیتابیس‌های مختلف اجرا شده باشد.
در چنین شرایطی، تغییر فایل قدیمی لزوماً تغییر مورد نظر را روی دیتابیس‌های موجود اعمال نمی‌کند.
# Migrationهای مخرب را با احتیاط استفاده کنید
دستورهایی مانند:
$table->dropColumn('old_column');
یا:
Schema::dropIfExists('products');
می‌توانند داده‌ها یا ساختار مهمی را حذف کنند.
در Production باید قبل از چنین تغییراتی مشخص شود:
- آیا داده قدیمی هنوز استفاده می‌شود؟
- آیا کد جدید و قدیم همزمان اجرا می‌شوند؟
- آیا Backup داریم؟
- آیا APIهای قدیمی هنوز به ستون مورد نظر وابسته هستند؟
- آیا حذف ستون باید در یک مرحله انجام شود یا چند مرحله؟
در پروژه‌های بزرگ معمولاً تغییرات حساس دیتابیس به صورت مرحله‌ای انجام می‌شوند.
# اشتباهات رایج در کار با Migration
۱. اجرای migrate:fresh روی Production
این یکی از خطرناک‌ترین اشتباهات است:
php artisan migrate:fresh
این دستور جدول‌ها را حذف می‌کند.
۲. ویرایش Migration قدیمی
اگر Migration قبلاً در Production اجرا شده است، معمولاً برای تغییرات جدید یک Migration جدید ایجاد کنید.
۳. استفاده بیش از حد از Index
Index برای Queryهای مناسب مفید است، اما ایجاد Index برای تمام ستون‌ها الزاماً باعث بهتر شدن عملکرد نمی‌شود.
۴. نادیده گرفتن Foreign Key
اگر جداول با یکدیگر رابطه دارند، طراحی Foreign Key مناسب می‌تواند به حفظ یکپارچگی داده‌ها کمک کند.
۵. استفاده نادرست از nullable
هر ستونی که nullable() شود، می‌تواند NULL داشته باشد.
بنابراین نباید صرفاً برای جلوگیری از خطا، تمام ستون‌ها را Nullable کنیم.
۶. ذخیره مبلغ با Float
برای مقادیر مالی معمولاً استفاده از ساختارهای دقیق مانند decimal مناسب‌تر از float است.
مثلاً:
$table->decimal('price', 12, 2);
# بهترین روش برای مدیریت Migration در پروژه Laravel
یک روند مناسب می‌تواند این باشد:
نیاز جدید
↓
بررسی ساختار دیتابیس
↓
ساخت Migration جدید
↓
نوشتن up()
↓
نوشتن down()
↓
اجرای Migration در Development
↓
تست برنامه
↓
بررسی Production Impact
↓
Backup
↓
Deploy
↓
php artisan migrate --force
این روند باعث می‌شود تغییرات دیتابیس قابل کنترل‌تر باشند.
# Migration، Seeder و Factory در کنار هم
در پروژه‌های واقعی معمولاً سه ابزار را کنار هم می‌بینیم:
Migration
↓
ساختار دیتابیس
Seeder
↓
داده اولیه
Factory
↓
تولید داده آزمایشی
مثلاً ابتدا Migration جدول products را ایجاد می‌کند.
بعد Seeder می‌تواند چند دسته‌بندی اولیه ایجاد کند.
سپس Factory می‌تواند هزار محصول آزمایشی برای تست ایجاد کند.
این سه مفهوم در ادامه مسیر آموزش Laravel بسیار مهم هستند.
# جمع‌بندی
Migration یکی از بخش‌های اساسی Laravel برای مدیریت ساختار دیتابیس است.
با Migration می‌توانیم ساختار جدول‌ها، ستون‌ها، Indexها و Foreign Keyها را به صورت کد تعریف کنیم و تغییرات دیتابیس را در کنار سورس پروژه مدیریت کنیم.
دستورات مهمی که در این مقاله یاد گرفتیم عبارت‌اند از:
php artisan make:migration create_products_table
php artisan migrate
php artisan migrate:status
php artisan migrate:rollback
php artisan migrate:reset
php artisan migrate:refresh
php artisan migrate:fresh
و برای محیط Production:
php artisan migrate --force
مهم‌ترین نکته این است که Migration را فقط یک ابزار برای «ساخت جدول» در نظر نگیریم؛ Migration در واقع روشی برای مدیریت نسخه‌ها و تغییرات ساختار دیتابیس در طول عمر پروژه است.
در مقاله بعدی، سراغ Seeder در Laravel می‌رویم و یاد می‌گیریم چگونه داده‌های اولیه و پیش‌فرض را به صورت اصولی وارد دیتابیس کنیم.
