rake db: схема: загрузка и миграция
Здесь очень простой вопрос: если миграция может стать медленной и громоздкой, так как приложение становится более сложным, и если у нас есть более чистый rake db:schema:load to call вместо этого, почему вообще существуют миграции?
Если ответ на вышеизложенное заключается в том, что миграция используется для контроля версий (поэтапная запись изменений в базе данных), тогда, когда приложение становится более сложным и rake db:schema:load используется вместо этого, они продолжают поддерживать свои основная функция?
Внимание:
Из ответов на этот вопрос: rake db:schema:load будет удалять данные на производственном сервере, поэтому будьте осторожны при его использовании.
Миграции обеспечивают переходы вперед и назад в базу данных. В производственной среде в процессе развертывания должны быть внесены дополнительные изменения в базу данных: миграции обеспечивают эту функциональность отказоустойчивым откатом. Если вы используете rake db: schema: load на производственном сервере, вы в конечном итоге удалите все свои производственные данные. Это опасная привычка.
При этом я считаю, что приличная практика иногда «сворачивает» миграции. Это приводит к удалению старых миграций, заменяя их одной миграцией (очень похожей на ваш файл schema.rb) и обновляя таблицу «schema_migrations», чтобы отразить это изменение. ОЧЕНЬ ОСТОРОЖНО, КОГДА ЭТО! Вы можете легко удалить производственные данные, если не будете осторожны.
В качестве примечания я твердо верю, что вы никогда не должны ставить создание данных в файлы миграции. Для этого может использоваться файл seed.rb или пользовательские задачи rake или deploy. Включение этого в файлы миграции смешивает спецификацию схемы базы данных с вашими спецификациями данных и может привести к конфликтам при запуске файлов миграции.
Просто наткнулся на этот пост, который был давно и не видел ответа, которого я ожидал.
rake db:schema:load великолепна при первом запуске системы. После этого вы должны нормально выполнять миграции.
Это также помогает вам очищать ваши миграции, когда захотите, поскольку схема содержит всю информацию, чтобы поставить другие машины в производство, даже если вы очистили свои миграции.
Миграции позволяют добавлять данные в базу данных. но db: schema: загрузка загружает только схему.
Поскольку миграция может быть откатна и обеспечить дополнительную функциональность. Например, если вам нужно изменить некоторые данные как часть изменения схемы, вам нужно будет сделать это как миграцию.
Как пользователь других ORM мне всегда казалось странным, что у Rails не было функции синхронизации и обновления. т.е., используя файл схемы (который представляет всю последнюю обновленную схему), просматривайте существующую структуру БД и добавьте / удалите таблицы, столбцы, индексы по мере необходимости.
Для меня это было бы намного более надежным, даже если возможно немного медленнее.
Я уже опубликовал в качестве комментария, но считаю, что лучше оставить комментарии файла 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's strongly recommended that you check this file into your version control system.
На самом деле, мой опыт заключается в том, что лучше разместить файлы миграции в git, а не в файле schema.rb …
rake db:migrate настроить таблицы в базе данных. Когда вы запустите команду миграции, она будет выглядеть в db / migrate / для любых rubyовых файлов и выполнять их, начиная с самого старого. В начале каждого имени файла миграции есть отметка времени.
В отличие от rake db:migrate который запускает миграции, которые еще не запущены, rake db:schema:load загружает схему, которая уже сгенерирована в db/schema.rb в базу данных.
Здесь вы можете узнать больше о командах базы данных rake .