Миграции и первая таблица в Laravel: что знать до старта

К концу этой инструкции у вас будет таблица posts, созданная не руками в phpMyAdmin, а миграцией — PHP-файлом, который можно применить, откатить и повторить на любой машине командой. Займёт минут двадцать, если база уже подключена. Пишу для Laravel 11.x — команды и структура папок в 10.x те же, отличий в базовом сценарии нет.

Что нужно иметь до начала

Прежде чем набирать первую команду, проверьте, что всё на месте. Иначе споткнётесь не на миграции, а на подключении к базе — и потратите время не туда.

• PHP 8.2 или новее — минимум для Laravel 11. Проверка: php -v.
• Composer и уже установленный проект Laravel. Если проекта нет: composer create-project laravel/laravel my-app.
• Работающая база — MySQL, PostgreSQL, MariaDB или SQLite. Для первого раза проще всего SQLite: файл вместо сервера, ничего поднимать не нужно.
• Доступ к терминалу в корне проекта — там, где лежит файл artisan.

Подключение базы: файл .env

Настройки подключения живут в файле .env в корне проекта, а не внутри PHP-кода. Для SQLite достаточно двух строк — создайте пустой файл базы и укажите драйвер:

# создать файл базы (Linux/macOS)
touch database/database.sqlite

# в .env оставить только это, остальные DB_* строки удалить или закомментировать
DB_CONNECTION=sqlite

Для MySQL строки другие — хост, порт, имя базы, логин, пароль:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=my_app
DB_USERNAME=root
DB_PASSWORD=YOUR_DB_PASSWORD

Проверка: выполните php artisan migrate:status. Если подключение живое, увидите таблицу статусов миграций (пока с системными). Если вылезла ошибка вида SQLSTATE[HY000] [1045] Access denied — неверный логин или пароль в .env, до таблиц дело ещё не дошло.

Что такое миграция и зачем она вместо ручного SQL

Миграция — это PHP-класс с двумя методами: up() описывает изменения (создать таблицу, добавить колонку), down() их откатывает. Laravel хранит в служебной таблице migrations, какие файлы уже применены, и не запускает их дважды.

Ручной SQL в phpMyAdmin живёт только в вашей голове и на одном сервере. Миграция — это версионируемая история схемы: коллега клонирует репозиторий, выполняет одну команду и получает ровно ту же структуру таблиц, что у вас.

Шаг за шагом: первая таблица

1. Создайте файл миграции. Флаг --create сразу подставит имя таблицы в шаблон:

   php artisan make:migration create_posts_table --create=posts

   Проверка: в папке database/migrations/ появился новый файл с датой в имени, например 2025_01_15_100000_create_posts_table.php.

2. Опишите колонки. Откройте созданный файл. Внутри up() добавьте нужные поля через объект $table:

   <?php
   
   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('posts', function (Blueprint $table) {
               $table->id();                 // BIGINT автоинкремент, первичный ключ
               $table->string('title');      // VARCHAR(255)
               $table->text('body');         // TEXT под тело статьи
               $table->boolean('published')->default(false);
               $table->timestamps();         // created_at и updated_at
           });
       }
   
       public function down(): void
       {
           Schema::dropIfExists('posts');
       }
   };

   Почему так: метод timestamps() нужен, потому что Eloquent по умолчанию сам заполняет created_at и updated_at — без этих колонок модель упадёт с ошибкой.

3. Примените миграцию. Одна команда прогоняет все ещё не применённые файлы:

   php artisan migrate

   Проверка: в выводе появится строка вида DONE напротив имени вашей миграции. Таблица posts теперь существует в базе.

4. Убедитесь, что таблица создана. Быстрее всего — через встроенную команду осмотра схемы:

   php artisan db:table posts

   Проверка: увидите список колонок: id, title, body, published, created_at, updated_at.

Откат: когда ошиблись в структуре

Пока таблица пустая и вы её только что создали, самый чистый способ исправить схему — откатить последнюю партию миграций, поправить файл и накатить снова:

# откатить последнюю группу применённых миграций
php artisan migrate:rollback

# полностью снести все таблицы и накатить с нуля
php artisan migrate:fresh

Важно про боевую базу: migrate:fresh удаляет все таблицы и все данные. На проде это катастрофа. На пустой локальной базе — нормальный рабочий приём, пока вы правите структуру. На данных лучше писать новую миграцию, которая меняет таблицу, а не откатывать старую.

Частые правила именования колонок

Чтобы не гадать, какой метод под какой тип, держите под рукой соответствие. Полный список — в документации, здесь самое ходовое:

Модификаторы вешаются цепочкой: $table->string('slug')->unique()->nullable(); — уникальное поле, которое может быть пустым.

Если не получилось

• SQLSTATE[HY000] [1045] Access denied for user — неверный логин или пароль в .env. После правки .env выполните php artisan config:clear: Laravel мог закешировать старые настройки.
• could not find driver — в PHP не включено расширение под вашу базу: pdo_mysql для MySQL или pdo_sqlite для SQLite. Проверьте php -m и включите расширение в php.ini.
• SQLSTATE[HY000] [14] unable to open database file (SQLite) — файл базы не создан или указан неверный путь. Создайте database/database.sqlite и проверьте права на запись.
• Nothing to migrate — миграция уже применена. Если правили её файл после накатывания, изменения не подхватятся: нужен migrate:rollback и повторный migrate, либо новая миграция.
• Table 'posts' already exists — таблица создавалась раньше вручную или другой миграцией. Удалите её или используйте migrate:fresh на пустой базе.

Что делать дальше

Таблица есть — теперь под неё нужна модель Eloquent, чтобы работать с записями из кода, а не писать SQL: php artisan make:model Post. Дальше стоит разобрать сидеры (наполнение таблицы тестовыми данными командой php artisan db:seed) и связи между таблицами через foreignId. Изменение уже существующей таблицы с данными — отдельная тема: там нельзя просто откатить и накатить заново, нужны миграции с Schema::table(). Держите в голове одно правило: любое изменение схемы на проде проходит только новой миграцией, старые применённые файлы не трогаем.