Насколько критично использование миграций в Laravel для одиночного проекта с одним разработчиком?

Question

[Роман]

Здравствуйте.

Я уже понял, что миграции в Laravel - эдакая система контроля версий для структуры БД.

Скажите, насколько критично использование миграций в проекте, где один веб-разработчик (я) и десяток таблиц с десятком полей каждая (грубо говоря).

Я только начинаю изучение Laravel и меня весь этот избыточный функционал в виде миграционных роллбэков и пр. - только запутывает. Мне проще по-старинке - через phpMyAdmin и дампы работать.

Будет ли нормальным в такой ситуации не прибегать к миграциям вовсе?

И смогу ли я потом, при необходимости (например, в проект добавятся другие разработчики или еще чего) создать необходимые миграции?

Спасибо.

Comments

[JhaoDa]

Ну продолжай, раз проще. Нет, это не будет нормальным, но тебе же плевать?

[Роман]

JhaoDa, здесь ключевое слово - критичность.

Т.е. влияет на конечный результат или не влияет.

Влияет на простоту модификации или не влияет.

Я пока не вижу каким образом миграции могут облегчить жизнь одинокого разработчика.

Потому и интересуюсь.

[JhaoDa]

procode, но при этом ты считаешь, что они могут её усложнить. Хотя критерии одни и те же.

[Роман]

JhaoDa, почему "могут" - они ее реально усложняют - у меня сейчас проект с изначально заданной структурой таблиц (из стороннего приложения) - мне эти таблицы дали уже в виде SQL-дампа.

И я не вижу никакого смысла в том, чтобы переводить этот дамп в формат миграций и уже оттуда их вставлять в базу - мне проще импортировать их через phpmyadmin и все.

Но, возможно, я что-то упускаю.

Поэтому решил посоветоваться с сообществом.

[Кирилл Несмеянов]

procode, ты можешь с тем же успехом этот первый дамп обернуть в одну миграцию с одной операцией - импортом этой БД.

[Роман Сохарев]

Поддерживаю Кирилла. Заверни импорт дампа в первую миграцию.

[Роман]

Кирилл Несмеянов, а разве так можно?

То есть мне не придется переписывать всё в формат Eloquent?

[Кирилл Несмеянов]

procode, конечно! Там целых 3 строчки придётся писать ='(

public function up(): void
{
    DB::unprepared(DB::raw(\file_get_contents(__DIR__ . '/2019_06_02_xxxx_init.sql')));
}

[Роман]

Кирилл Несмеянов, просто вау!)) То что нужно! Спасибо!

[Роман]

Кирилл Несмеянов, стати, а __DIR__ куда в данном случае указывает? На папку с миграцией?

[Кирилл Несмеянов]

procode, куда угодно. Никто не ограничивает в выборе структуры кода.

Answer 1

[Роман]

Ответ от Алексея в комментариях здесь: https://toster.ru/answer?answer_id=1340557#comment...

Answer 2

[Pavel Omelchenko]

Миграции всегда и везде, они нужны не для команды или кого-то еще, а для версионирования изменений в базе. Это все равно что "а нужно ли мне использовать гит, если я один разраб в проекте?!" – да, черт возьми, нужно!

Чем раньше вы привыкните к правильному подходу, тем выше ваша ценность в сообществе.

Comments

[Роман]

Хорошая аналогия с Гитом, но я, если честно, использую Гит только тогда, когда мне нужно что-нибудь запилить на Гитхаб для общего доступа))

А так, обычно просто храню архивы с ключевыми точками разработки проекта :)

Я несколько раз пытался освоить Гит - но у меня так и не получилось. Мне он кажется слишком мудреным.

[Кирилл Несмеянов]

procode, Ctrl+K в шторме нажать и написать "Поправил Ололо" - это, типа, сложно? А потом видеть всю историю и откатиться на любой момент времени одной кнопочкой....

[Роман]

Кирилл Несмеянов, я в Notepad++ пишу)) но, возможно, теперь присмотрюсь к шторму внимательней -)

[Pavel Omelchenko]

procode, в смысли аналогия? Это факт, их для версионирования изменений базы и придумывали. Если для вас гитхаб это всего лишь файлообменник, то это прискорбно. Брать на изучение инструменты и выкидывать основные его функции...

[Роман]

Pavel Omelchenko, мне от Ларавеля нужен, в основном, роутинг, авторизация, и фильтры для форм. Может со временем запросы и возрастут, но не теперь.

[Pavel Omelchenko]

procode, у вас странный подход к разработке. Очень странный

[Роман]

Pavel Omelchenko, возможно, но другого у меня нет))