От массива — к базе

В части 3 UserController::index() передавал шаблону массив, записанный прямо в коде. Для страницы этого хватило, но данные у такого решения бумажные: PHP-FPM обрабатывает каждый запрос заново и ничего не помнит между запросами (жизненный цикл запроса вы разбирали в lesson.network.02). Пользователь не может ни добавить запись, ни исправить её — для этого пришлось бы менять код.

Хранить данные нужно вне процесса: в файле или в базе. Мы берём базу — ту самую MariaDB, с которой вы работали весь блок lesson.db.

Каждый этап заканчивается проверяемым результатом: выводом команды, строкой в базе или страницей в браузере.

По умолчанию Laravel работает с SQLite

Смотрим два факта. В .env на строке 23 стоит DB_CONNECTION=sqlite, а строки 24–28 — DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD — закомментированы. Каркас заранее приготовил вариант «серверная СУБД»: его нужно только раскомментировать и заполнить.

Рядом лежит database/database.sqlite — 106496 байт, права -rw-rw-rw-, время создания Oct 17 10:20. Это не сервер, а обычный файл: миграции в него уже прошли при установке проекта (часть 1), поэтому он не пустой.

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

Приборная панель соединения: php artisan db:show

db:show отвечает на вопрос «куда приложение смотрит прямо сейчас». Здесь: SQLite 3.45.1, соединение sqlite, база — путь к файлу, а Host, Port, Username и URL пустые. Пустые не потому, что вывод сломался: подключаться не к кому, файл открывает сам процесс PHP. Tables 9, а размеры таблиц — прочерки: SQLite их так не отдаёт.

Запомните цифру 9: мы не написали ни строчки SQL, а схема уже есть. Её создали миграции каркаса при установке. Чуть ниже разберём, откуда они взялись и что в них.

MariaDB на месте, и root заходит без пароля

Это тот самый консольный клиент из lesson.db.vi.01 — только без привычных -u root -p: пароль не спросили. Версия на стенде — 10.11.14-MariaDB-0ubuntu0.24.04.1. В списке четыре служебные базы (information_schema, mysql, performance_schema, sys); нашей пока нет.

Почему пускает без пароля: у учётки root@localhost в MariaDB на Ubuntu и Mint включён плагин unix_socket. Сервер проверяет не пароль, а то, что соединение пришло через локальный сокет и что ОС-пользователь — root (мы вошли через sudo). Доверие берётся из операционной системы.

Но приложение так зайти не сможет

Та же MariaDB, тот же root — и ERROR 1698 (28000): Access denied for user 'root'@'localhost', код выхода 1. Отличие от прошлой команды одно: -h 127.0.0.1, то есть мы пришли по TCP, а не через unix-сокет. Плагину unix_socket нечего проверять — у сетевого соединения нет ОС-пользователя, поэтому в доступе отказано.

Почему это касается нас напрямую: Laravel подключается к базе так, как написано в .env — DB_HOST=127.0.0.1, DB_PORT=3306, то есть по TCP. Значит, под root приложение не заработает никогда, сколько бы раз мы ни перезапускали nginx и php-fpm. Ошибка при этом выглядит обидно непонятной: «в терминале заходит, из кода — нет».

Заводим базу и пользователя приложения

Один вызов sudo mysql -e с четырьмя командами и контрольный SHOW DATABASES: в списке появилась project_laravel. Разбор по частям:

• CREATE DATABASE IF NOT EXISTS project_laravel с CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci — имя базы совпадает с проектом и доменом project-laravel.rs из части 2. IF NOT EXISTS делает команду повторимой: второй запуск не упадёт. utf8mb4 — полноценный UTF-8, до четырёх байт на символ, поэтому кириллица и прочие символы не обрезаются; utf8mb4_unicode_ci — правила сравнения строк, ci в названии означает «без учёта регистра».
• CREATE USER IF NOT EXISTS 'project_laravel'@'localhost' IDENTIFIED BY 'secret' — отдельная учётка именно для приложения. Запись 'project_laravel'@'localhost' читается как «пользователь project_laravel, пришедший с localhost».
• GRANT ALL PRIVILEGES ON project_laravel.* TO 'project_laravel'@'localhost' — все права, но только внутри project_laravel: маска project_laravel.* — это все таблицы одной базы и ничего за её пределами.
• FLUSH PRIVILEGES — перечитать таблицы прав, чтобы изменения подействовали сразу, без перезапуска сервера.

Смысл отдельного пользователя — минимальные права. Если пароль утечёт или запрос соберётся из пользовательских данных неправильно, ущерб ограничен одной базой. Это тот же принцип, что и в lesson.sql-injection.i.03: не «разрешить всё и потом проверять», а заранее сузить набор возможного.

Миграция — это изменение схемы, записанное кодом

Структуру таблицы вы уже меняли руками: в lesson.dbii.03 тип поля category правили запросом ALTER TABLE из phpMyAdmin. Работает, но у такого изменения нет истории — оно осталось в базе и в памяти того, кто его делал.

Миграция — тот же ALTER TABLE (или CREATE TABLE), но записанный в PHP-файл в каталоге database/migrations/. У файла два метода: up() — что сделать, down() — как отменить. Файл попадает в git, и любая машина — ваша, коллеги, боевой сервер — получает одинаковую схему одной командой.

Порядок обеспечивает имя файла: 2026_10_17_102101_add_phone_to_users_table.php начинается с даты и времени создания. Laravel применяет файлы по алфавиту, то есть хронологически, и помнит в базе, какие уже выполнены.

Пересоздаём схему уже в MariaDB

Читаем вывод сверху вниз:

• Preparing database → Creating migration table ... 30.43ms DONE. Laravel создал служебную таблицу migrations — журнал применённых миграций. Её не было, потому что база project_laravel создана только что.
• Running migrations → три файла, каждый со своим временем: 211.97ms, 135.60ms, 221.05ms. Это миграции каркаса, мы их не писали: они лежат в database/migrations/ с момента установки проекта.

Имена говорят сами за себя: create_users_table, create_cache_table, create_jobs_table. Внутри этих файлов — обычный PHP с вызовами Schema::create(...), из которых Laravel собирает SQL под текущую СУБД. Какие именно таблицы кто создаёт, посмотрим на следующем слайде.

Журнал миграций: php artisan migrate:status

Три строки — три применённые миграции, у всех батч [1] и статус Ran. Батч — это «пачка»: всё, что применилось одним запуском migrate, получает общий номер. Именно батчами работает откат: migrate:rollback --step=1 отменяет последний из них.

Зачем эта команда в ежедневной работе: она отвечает на два вопроса — что база уже видела и какие файлы лежат на диске, но ещё не применены. Ситуация «локально работает, а на сервере нет колонки» почти всегда означает, что на сервере просто не запустили migrate; migrate:status показывает это за одну секунду.

Нужна колонка phone — делаем новую миграцию

Приложение хранит ФИО, телефон, email и пароль, но колонки phone в таблице нет: каркас о ней не знает. Добавляем.

artisan превращает имя миграции в имя файла: add_phone_to_users_table → database/migrations/2026_10_17_102101_add_phone_to_users_table.php, где префикс — дата и время создания. Параметр --table=users подсказывает генератору, что менять будем существующую таблицу: в заготовке сразу появится Schema::table('users', ...), а не Schema::create(...).

Применяем и смотрим схему

migrate запустил ровно один файл — наш, за 48.72ms. Три миграции каркаса он не трогал: они уже в журнале. Это и есть обычный рабочий цикл — добавили файл, выполнили migrate, ничего лишнего не пересоздалось.

DESCRIBE users теперь показывает девять колонок: phone varchar(32), NO в столбце Null, стоит третьей — сразу после name. Сработал ->after('name').

Миграцию можно откатить

В захвате три команды подряд, и читать их надо вместе с выводом:

1. php artisan migrate:rollback --step=1 — отменил последний батч: Rolling back migrations, наш файл, 53.27ms DONE.
2. mysql ... -e "SHOW COLUMNS FROM users LIKE 'phone';" — между двумя блоками INFO в выводе пусто. Это и есть ответ: запрос не вернул ни одной строки, колонки phone больше нет. down() отработал.
3. php artisan migrate — применил миграцию заново, 43.53ms DONE.

Пустой вывод — тоже вывод. SHOW COLUMNS ... LIKE печатает заголовок таблицы только тогда, когда есть что печатать; тишина означает «не нашлось».

Пробуем модель в tinker

php artisan tinker запускает интерактивную консоль внутри приложения: Laravel загружен, .env прочитан, соединение с базой установлено, все классы доступны. Флаг --execute='...' выполняет одну строку и выходит — так удобнее и писать проверки, и снимать вывод.

Что происходит в этой строке:

• App\Models\User::create([...]) — статический вызов модели. Массив из четырёх полей превращается в INSERT. Все четыре есть в #[Fillable], поэтому все четыре и записались.
• echo "id=" . $u->id — после вставки объект знает свой первичный ключ: id=1. В курсе вы получали его вручную через PDO::lastInsertId().
• created_at и updated_at модель проставила сама: в DESCRIBE users эти колонки есть, а в массиве мы их не передавали.

В базе лежит не пароль, а его хеш

Мы передали 'password' => 'secret', а запрос value('password') вернул строку из 60 символов. Разбираем префикс $2y$12$:

• $2y$ — идентификатор алгоритма bcrypt;
• 12 — стоимость, то есть число раундов; ровно столько задано в .env строкой BCRYPT_ROUNDS=12;
• дальше — соль и результат в одной строке.

Хеширование сделал каст 'password' => 'hashed' из casts() модели: значение превращается в хеш в момент присваивания, до INSERT. В SQL-запрос открытый пароль не попадает.

Зачем это нужно. Хеш необратим: из $2y$12$... нельзя получить secret, можно только перебирать варианты и сравнивать. Стоимость 12 делает каждый перебор заметно дороже, чем «просто быстрый хеш». Если база утечёт, злоумышленник получит хеши, а не пароли, которыми люди пользуются на других сайтах.

В lesson.http.iii.02 вы собирали форму регистрации, и ведущий отдельно отметил: пароль уходит в POST открытым текстом. Открытым он и должен ехать — его защищает транспорт (HTTPS), — но храниться в базе в таком виде он не должен никогда. А #[Hidden] не даёт хешу вернуться обратно в HTML или JSON.

Что Eloquent на самом деле отправляет в MariaDB

DB::enableQueryLog() включает журнал запросов, DB::getQueryLog() его печатает. Один вызов User::where('email', 'like', '%example%')->get() дал один запрос — select * from `users` where `email` like ? — и отдельно массив bindings со значением %example%. Время выполнения — 2.71 ms.

Главное: значения внутри строки запроса нет. На его месте ?, а само значение едет рядом, в bindings. Это prepared statement — ровно то, что вы делали руками в lesson.db.04: шаблон запроса с маркерами, prepare() и execute() с параметрами. Laravel не отменяет эту защиту, он забирает себе рутину.

Обратные кавычки вокруг users и email — тот самый «gravis» из lesson.db.04: так SQL отличает имена таблиц и колонок от значений и от служебных слов.

Убираем тестовую запись

where(...)->delete() — это DELETE FROM users WHERE email = ?, а count() — SELECT count(*). Осталось 0: таблица снова пуста, дальше наполним её сидером.

Заодно заметьте деталь, которая объяснит следующий вывод: запись с id=1 удалена, но следующая вставка получит id=2. AUTO_INCREMENT не возвращает освободившиеся номера — иначе удалённая запись и новая стали бы неразличимы в логах, ссылках и внешних системах.

Сидер: данные для разработки одной командой

Список из одной записи пагинацию не покажет, а набирать 12 пользователей руками долго и неповторимо: завтра вы пересоздадите базу и начнёте заново. Сидер — класс, который наполняет базу данными. Запустили команду — получили одинаковый набор на любой машине.

php artisan make:seeder UsersSeeder создал файл database/seeders/UsersSeeder.php. Приём вам знаком: в lesson.db.04 вы вставляли 42 ресторана циклом foreach по массиву из парсера. Сидер — тот же цикл, только он лежит в проекте и вызывается командой db:seed.

Запускаем и смотрим, что попало в базу

Сидер отработал за 3,973 ms — и это не вставка такая медленная. Время съедают 12 вычислений bcrypt со стоимостью 12: хеш намеренно дорогой, иначе его было бы дёшево перебирать.

Что видно в первых шести строках из двенадцати:

• id начинается с 2, а не с 1: единицу заняла удалённая тестовая запись, AUTO_INCREMENT её не вернул — ровно то, о чём мы говорили перед сидером;
• кириллица в name сохранилась как есть: работает utf8mb4, который мы задали при создании базы;
• телефоны вида +7 (912) 345-67-89 — 18 символов, в varchar(32) помещаются с запасом;
• LEFT(password, 7) у всех строк даёт $2y$12$ — префикс алгоритма и стоимость. Полные хеши в вывод не тащим намеренно.

Контроллер читает из базы, а не из массива

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

lastPage() — это ваш ceil($count / $perPage) из lesson.http.ii.05, только считает его пагинатор сам: 12 записей по 5 на страницу → 3 страницы, последняя неполная.

У пагинатора есть готовый метод links(), который рисует ссылки на все страницы одной строкой. Мы его не используем: links() приносит собственную HTML-разметку, рассчитанную на классы Tailwind CSS, а у нас свои стили и свой класс .pager. Поэтому разметку «назад · 1 / 3 · вперёд» собираем сами из методов таблицы: их поведение предсказуемо, а внешний вид полностью наш.

Одна страница = два запроса

Тот же приём с журналом запросов: paginate(5) выполнил ровно два запроса.

1. select count(*) as `aggregate` from `users` — сколько всего строк. Без этого числа пагинатор не знает ни lastPage(), ни есть ли следующая страница.
2. select * from `users` order by `name` asc limit 5 offset 0 — сами данные: пять строк, начиная с нулевого смещения.

bindings пусты в обоих случаях: ни сортировка, ни размер страницы не пришли от пользователя, подставлять нечего. Для ?page=2 второй запрос пойдёт с offset 5.

Именно эту пару вы собирали руками в lesson.http.ii.05: SELECT COUNT(...) для числа страниц и LIMIT с OFFSET для среза. Laravel не придумал новый способ — он спрятал арифметику внутрь объекта.

Проверяем через HTTP

curl проходит весь этот путь и возвращается ответом HTML — ровно как браузер.

Что видно на первой странице:

• <h1>Пользователи <span class="muted">(12)</span></h1> — total() вернул 12, это результат COUNT(*);
• навигация и открывающий <main class="page"> — из макета layouts/app.blade.php (часть 3);
• строки идут по алфавиту: Васильева, Егорова, Иванов — работает orderBy('name'), а collation utf8mb4_unicode_ci сортирует кириллицу по алфавиту, а не по кодам байтов;
• сам вывод обрезан: команда sed -n "12,40p" показала строки 12–40 HTML, поэтому третья запись попала в кадр не целиком.

Вторая страница — ?page=2, а grep -o "<td>[^<]*</td>" | head -9 достал девять ячеек, то есть три записи: Морозова, Николаев, Петрова. Это шестая, седьмая и восьмая фамилии по алфавиту — прямое продолжение первой страницы. Шаблон тот же, изменился только offset в запросе.

Приборная панель после переключения

Сравните с началом части. Вместо SQLite 3.45.1 и пустых Host/Port/ Username — MariaDB 10.11.14, 127.0.0.1, 3306, project_laravel, база project_laravel. Таблиц по-прежнему 9, но появились размеры: всего 304.00 KB, из них users — 64.00 KB.

Эта команда — первый ответ на вопрос «куда приложение вообще пишет?». Если данные сохраняются, а вы их не видите (или наоборот), db:show показывает соединение, которое используется на самом деле. Нередко оказывается, что проект смотрит не в ту базу или всё ещё в SQLite-файл.

Проверьте себя

1. Почему приложение не может подключиться к MariaDB как root, хотя в терминале sudo mysql пускает без пароля?
2. Чем php artisan migrate:fresh отличается от php artisan migrate, и какая из этих команд уничтожает данные?
3. Колонку phone можно было добавить прямо в миграцию create_users_table. Почему мы вместо этого создали новый файл?
4. В create([...]) пароль передали как 'secret', а в таблице лежит $2y$12$.... Кто и в какой момент превратил одно в другое?
5. paginate(5) выполняет два запроса. Какие это запросы и зачем нужен второй?

Ответы

1. Учётка root@localhost аутентифицируется плагином unix_socket: сервер проверяет, что соединение пришло через локальный сокет и что ОС-пользователь — root. Приложение соединяется по TCP 127.0.0.1:3306, там проверять нечего — ERROR 1698. Нужен отдельный пользователь с паролем.
2. migrate применяет только те файлы, которых ещё нет в журнале migrations; migrate:fresh сначала удаляет все таблицы текущего соединения, а затем прогоняет миграции заново. Данные уничтожает вторая команда.
3. Применённая миграция уже записана в журнал: на вашей машине правка ничего не изменит, на чистой — изменит, и схемы разойдутся при одинаковом коде. История схемы неизменяема, как история коммитов.
4. Каст 'password' => 'hashed' в методе casts() модели: значение хешируется bcrypt при присваивании, до INSERT. Стоимость задаёт BCRYPT_ROUNDS=12 из .env.
5. select count(*) as `aggregate` from `users` — общее число записей, из него пагинатор знает lastPage() и наличие следующей страницы; и select * from `users` order by `name` asc limit 5 offset 0 — сами пять строк текущей страницы.

Что дальше

База подключена, схема описана кодом, данные есть, список показывается страницами. Но приложение пока умеет только читать: добавить, поправить и удалить пользователя нельзя. В макете есть ссылка «Добавить» на /users/create (её видно в HTML выше), а маршрута за ней пока нет.

В части 5 — CRUD: добавить, изменить, удалить:

• ресурсные маршруты — одна строка вместо семи;
• формы добавления и правки, @csrf и почему POST без токена отвечает 419;
• валидация: правила для ФИО, телефона, email и пароля, русские сообщения об ошибках, проверка уникальности email с исключением текущей записи;
• что происходит с паролем при правке, если поле оставили пустым;
• удаление через форму, а не ссылкой, и почему так.

Всё нужное уже готово: модель User с белым списком полей, 12 записей в базе и шаблон списка, в который останется добавить кнопки действий.