Всем привет, решил начать изучение Laravel. Нас в универе учили проектировать базу данных в программах наподобие Erwin, там выбираешь нужную субд и тебе генерируется SQL-код. Начал смотреть курсы, читать статьи по фреймворку и что-то не вижу подобного, когда просто копируешь дамп базы и используешь ее напрямую. Правильно ли я понимаю, что в Laravel для каждой таблицы нужно создавать отдельную миграцию и выполнять ее по отдельности? Если да, то как нужно прописывать столбцы для базы? Их надо вручную добавлять в миграцию по одному?
Именно - в миграция и прописываете 1 миграция - 1 таблица, кроме того есть миграции по модификации существующих таблиц Как прописывать - посмотрите в документации к Ларе, там все четко и просто описано, и столбцы как, и какие типы есть, и индексы как прописать - все там есть Напрямую тоже можно, но обычное это там - где проект не с начала в Ларе, а откуда нибудь структура БД переносится уже. Просто пишите Seeder в котором читаете SQL файл - и система выполняет все действия по нему.
У нас такое не работает Тема нужна не только тебе, а и тем, кто придёт за тобой с поисковика. Она будет жить вечно. Да, всё так: дамп не пригодится, надо создавать в терминах Laravel, т.е. через миграции. Меня это тоже раздражало на первых порах. Возможно тебя устроит reverse engineering: создай базу своими любимыми средствами, затем по базе создай миграции. https://github.com/Xethron/migrations-generator Но это решение на один раз. Продолжать в том же духе при каждом изменении как-то накладно. Не всё выразимо через миграции, но если избегать сложных случаев, то норм. Есть специфические фишки. Например, незачем буквально описывать поля `created_at` + `updated_at`, а делать вот так: $table->timestamps(); --- Добавлено --- Я бы порекомендовал таки симитировать создание через Laravel, см. ссылку выше. Это упростит развёртывание local и staging окружения! Мне приходилось проделывать такие штуки чтобы сделать легаси проект действительно обслуживаемым. --- Добавлено --- Шаги для подхватывания существующей базы: - R.E. создание миграций в отдельном пустом проекте, затем копирование их в "родной" проект, зависимость от Xentron нам больше не нужна - попробовать создать новую базу - выгрузить `mysqldump --no-data` обе базы, сравнить файлы через любимый визуальный diff - поправить недочёты, если надо, вернуться ко 2-му шагу - создать сидеры для минимально рабочего состояния. в сидерах использовать конструкции вида PHP: public function run() { // It should run only once if (DB::table('tablename')->count() > 0) { return; } . . . } тогда деплой-скрипт может безопасно вызывать Код (Text): php artisan migrate --step --seed как в первый раз на пустой базу, так и при каждом накатывании изменений. - продолжать разработку как если бы это был новый блестящий проект, а не унаследованный.
ну это вряд ли все так идеально, ведь в старом легаси настолько наворочено бывает, да и структура зачастую не подходит
@ADSoft родной, я ведь нигде не написал, что всё идеально. Я описал шаги как привести описание к ларавелевскому стандарту. В этой задаче нет ничего запредельного. Зачастую (лол) кажется, что проще бросить имеющееся и переписать заново. Эта блестящая идея может закончиться таким же говном. А может и нет. Но задержка гарантирована. И есть конкретные шаги как двигаться к лучшему без остановки рабочего процесса. Выбирать тому, кто платит.
Up теме. Делаю reverse engineering в Laravel 6 по готовой структуре форума FluxBB v1.5. Миграции и классы моделей уже есть. Пишу аутентификацию/авторизацию. https://github.com/fluxbb-ru/laravel-fluxbb-connect