Rake db: схема: загрузка и миграция

Очень простой вопрос здесь - если миграции могут стать медленными и громоздкими, поскольку приложение становится более сложным, и если у нас есть гораздо более чистый rake db:schema:load для вызова, то почему миграции вообще существуют?

Если ответ на вышеизложенное заключается в том, что миграции используются для контроля версий (поэтапная запись изменений в базе данных), то по мере того, как приложение становится более сложным, а rake db:schema:load используется вместо этого, они продолжают поддерживать свои основная функция?

Внимание:

Из ответов на этот вопрос: rake db:schema:load удалит данные на производственном сервере, поэтому будьте осторожны при его использовании.

Ответ 1

Миграции обеспечивают переходы вперед и назад в базу данных. В производственной среде в процессе развертывания должны быть внесены дополнительные изменения в базу данных: миграции обеспечивают эту функциональность отказоустойчивым откатом. Если вы используете rake db: schema: load на производственном сервере, вы в конечном итоге удалите все свои производственные данные. Это опасная привычка вступать.

Говоря, я считаю, что достойная практика иногда "сворачивает" миграции. Это приводит к удалению старых миграций, заменяя их одной миграцией (очень похожей на ваш файл schema.rb) и обновляя таблицу "schema_migrations", чтобы отразить это изменение. ОЧЕНЬ ОСТОРОЖНО, КОГДА ЭТО! Вы можете легко удалить свои производственные данные, если не будете осторожны.

В качестве побочного примечания я твердо верю, что вы никогда не должны помещать создание данных в файлы миграции. Для этого может использоваться файл seed.rb или пользовательские задачи rake или deploy. Включение этого в файлы миграции смешивает спецификацию схемы базы данных с вашими спецификациями данных и может привести к конфликтам при запуске файлов миграции.

Ответ 2

Просто наткнулся на этот пост, который был давно и не видел ответа, который я ожидал.

rake db:schema:load отлично работает, когда вы вводите систему в эксплуатацию. После этого вы должны нормально выполнять миграции.

Это также помогает вам очищать ваши миграции, когда захочет, поскольку схема содержит всю информацию, чтобы поставить другие машины в производство, даже когда вы очистили свои миграции.

Ответ 3

Миграции позволяют добавлять данные в db. но db: schema: load загружает только схему.

Ответ 4

Поскольку миграция может быть отменена и предоставить дополнительные функции. Например, если вам нужно изменить некоторые данные как часть изменения схемы, вам нужно будет сделать это как миграцию.

Ответ 5

Как пользователь других ORM, мне всегда казалось странным, что у Rails не было функции синхронизации и обновления. т.е., используя файл схемы (который представляет всю последнюю обновленную схему), пройдите через существующую структуру БД и добавьте/удалите таблицы, столбцы, индексы по мере необходимости.

Для меня это было бы намного более надежным, даже если возможно немного медленнее.

Ответ 6

Я уже опубликовал как комментарий, но чувствую, что лучше поставить комментарии к файлу db/schema.rb здесь:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It strongly recommended that you check this file into your version control system.

На самом деле, мой опыт заключается в том, что лучше разместить файлы миграции в git, а не файл schema.rb...