Ещё один плюс использования открывается при работе в команде, если кто-то внес изменения в таблицу, вам придется гадать что пошло не так, при использовании миграций это проблема исчезает. Откатывать изменения можно полностью все или по шагам: *php artisan migrate:rollback --step=1* (2,3 на сколько этапов необходимо) Полный назад: *php artisan migrate:reset*
Смотрю твои видео с самого начала, так сейчас видно, что ты на глазах растёшь: подача материала, монтаж, музыка. Здорово. Лайк однозначно. З.Ы. присоединяюсь с прошлым комментариям, очень хотелось бы увидеть дальше. Более лучше воспринимаю твою информацию.
Важная вещь которую я не сразу понял. !!! Нельзя создать миграцию из уже готовой базы данных !!! Начинать наполнение базы таблицами нужно с создания миграции, и менять в дальнейшем ее тоже нужно только с помощью миграций. Ни в какой момент времени нельзя ничего делать руками в базе.
А можете пожалуйста объяснить, чем отличается допустим импорт дампа базы данных от миграций? зачем нужны миграции когда можно сделать экспорт/импорт дампа БД ?
Миграции это не дамп базы данных, это исключительно для разработки, обновления, для всей жизнедеятельности приложения, пока оно работает. Оно не связано с данными, оно связано со структурой и архитектурой.
Очень категоричное заявление, что миграция не отвечает за те данные, которые содержатся в таблице. Внутри методов up и down можно писать сильно больше чем команды создания/редактирования. Например, меняется архитектура БД, очень сильно меняется. Например, 2 таблицы А и Б объединяются в 3 В. В этом случае можно написать миграцию, которая на up: 1. создаст новую таблицу В 2. Перегонит из двух старых (А, Б) перегонит данные в В 3. Удалить старые таблицы А на down произведет обратные действия. Т.е. допускаются вообще любые действия с БД и не только, например за структурой можно сходить на сторонний ресурс и что-то там взять (Не делайте так, это не безопасно)
Ещё один плюс использования открывается при работе в команде, если кто-то внес изменения в таблицу, вам придется гадать что пошло не так, при использовании миграций это проблема исчезает.
Откатывать изменения можно полностью все или по шагам:
*php artisan migrate:rollback --step=1* (2,3 на сколько этапов необходимо)
Полный назад:
*php artisan migrate:reset*
Смотрю твои видео с самого начала, так сейчас видно, что ты на глазах растёшь: подача материала, монтаж, музыка. Здорово. Лайк однозначно.
З.Ы. присоединяюсь с прошлым комментариям, очень хотелось бы увидеть дальше. Более лучше воспринимаю твою информацию.
Спасибо! Расти всегда надо, путь назад это путь в никуда! Отдельное спасибо за то что так долго в команде!
Спасибо большое!Как всегда - все классно!
Спасибо!Круто можешь сделать подобное по фасадам и сервисам)Очень круто!
+
Вообще про паттерны в фреймворке Laravel было бы круто и по best практикам всяким.
Важная вещь которую я не сразу понял. !!! Нельзя создать миграцию из уже готовой базы данных !!! Начинать наполнение базы таблицами нужно с создания миграции, и менять в дальнейшем ее тоже нужно только с помощью миграций. Ни в какой момент времени нельзя ничего делать руками в базе.
Крутые у вас уроки, спасибо!
Круто,молодцы!
Больше практики пожалуйста)
А когда будет продолжение Vue.js и Laravel ????
А что будет со значениями после миграции ? Они просто пропадут ?
А можете пожалуйста объяснить, чем отличается допустим импорт дампа базы данных от миграций? зачем нужны миграции когда можно сделать экспорт/импорт дампа БД ?
Миграции это не дамп базы данных, это исключительно для разработки, обновления, для всей жизнедеятельности приложения, пока оно работает. Оно не связано с данными, оно связано со структурой и архитектурой.
Ну а что делать тем у кого в базе уже десятки схем и многие сотни таблиц ( случай нашей команды ).. миграции тут явно не помогут
Ты говоришь о таблице где можно хранить пол пользователя. А можно хранить четверть пользователя? XD
При желании можно все...
Очень категоричное заявление, что миграция не отвечает за те данные, которые содержатся в таблице. Внутри методов up и down можно писать сильно больше чем команды создания/редактирования. Например, меняется архитектура БД, очень сильно меняется. Например, 2 таблицы А и Б объединяются в 3 В. В этом случае можно написать миграцию, которая на up:
1. создаст новую таблицу В
2. Перегонит из двух старых (А, Б) перегонит данные в В
3. Удалить старые таблицы
А на down произведет обратные действия.
Т.е. допускаются вообще любые действия с БД и не только, например за структурой можно сходить на сторонний ресурс и что-то там взять (Не делайте так, это не безопасно)
+