В разгар разработки приложения Laravel 4 я решил начать использовать функцию переноса Laravel.Начните использовать Миграции в середине приложения Laravel
Вопрос: Должны ли мы писать миграции для создания всех таблиц, которые мы имеем в настоящее время в базе данных? Или мы только пишем миграции для будущих изменений?
На это нет полного правильного ответа. Все зависит от множества переменных, таких как ваш стиль разработки, количество людей, с которыми вы работаете, и в какой среде (отдельные производственные DB? Несколько dev-DB?), Каковы ваши требования с миграциями и т. Д. И т. Д. .
Если вы решите написать миграцию для всей БД до этого момента, вам необходимо убедиться, что ваши миграции могут обрабатывать любые потенциальные конфликты. Использование Schema::has() и таких, чтобы проверить, существуют ли таблицы до их создания и т. Д.
В качестве альтернативы вы можете писать миграции, как если бы у БД был чистый сланец, и принуждение всех разработчиков начать с пустой БД до запуска миграции. У этого есть риски, поэтому будьте осторожны. Убедитесь, что у вас есть резервные копии, если ваша миграция забыла что-то, и вам нужно его изменить.
Итак, TL; DR: Является ли использование миграции для всей вашей структуры частью через проект обязательно плохой? Нет. Правильно ли для вашей заявки? От этого все зависит.
Я думаю, что каждая таблица, которая «работает» в производственной среде, может быть фактически удалена из любого сценария миграции (не то, что я делаю), я бы сказал, не беспокойтесь. Экспортируйте текущую БД, и у вас есть свое «состояние ссылки». В конце концов, вот что такое миграция? Легко ли применять изменения в базах данных, которые еще не имеют изменений? – AmazingDreams