Когда (если) консолидировать миграции ActiveRecord?
Фиксированный означает, что каждая строка является точно тем же размером. Это означает, что, если 3-я строка на странице данных должна быть загружена, это будет в точно PageHeader+2*RowSize, сохраняя некоторое время доступа.
для нахождения начала динамической записи, со списком рекордных смещений нужно консультироваться, который включает дополнительную косвенность.
Короче говоря, да, существует небольшой хит производительности для динамических строк. Нет, это не очень большое. Если Вы думаете, что это будет проблема, тест для него.
6 ответов
Yes, this makes sense. There is a practice of consolidating migrations. To do this, simply copy the current schema into a migration, and delete all the earlier migrations. Then you have fewer files to manage, and the tests can run faster. You need to be careful doing this, especially if you have migrations running automatically on production. I generally replace a migration that I know everyone has run with the new schema one.
Other people have slightly different ways to do this.
I generally haven't done this until we had over 100 migrations, but we can hit this after a few months of development. As the project matures, though, migrations come less and less often, so you may not have to do it again.
This does go against a best practice: Once you check in a migration to source control, don't alter it. I make a rare exception if there is a bug in one, but this is quite rare (1 in 100 maybe). The reason is that once they are out in the wild, some people may have run them. They are recorded as being completed in the db. If you change them and check in a new version, other people will not get the benefit of the change. You can ask people to roll back certain changes, and re-run them, but that defeats the purpose of the automation. Done often, it becomes a mess. It's better left alone.
Я думаю, что есть два типа миграций:
те, которые вы сделали во время проектирования / разработки, потому что вы изменили свое мнение о том, какой должна быть ваша база данных;
те, которые вы сделали между выпусками, отражая некоторые изменения поведения.
Я избавляюсь от первого типа миграций, как только могу, поскольку они на самом деле не представляют собой рабочие выпуски, и сохраняю второй вид, так что теоретически возможно, для обновления приложения.
О символах и строках: многие утверждают, что при миграции следует использовать только строки: символы предназначены для «дескрипторов» объектов и не должны использоваться для представления имен (имена столбцов и таблиц в этот случай). Это чисто стилистическое соображение, но оно убедило меня, и я больше не использую символы в миграциях.
Я читал еще об одном пункте использования строк: "
Не следует удалять миграции. Зачем создавать дополнительную работу?
По сути, миграции - это набор инструкций, которые определяют, как построить базу данных для поддержки вашего приложения. Когда вы создаете свое приложение, миграции записывают повторяющиеся изменения, которые вы вносите в базу данных.
ИМХО, периодически сбрасывая базовый план, вы вносите изменения, которые могут привести к ошибкам / проблемам с вашим приложением, создавая дополнительную работу.
В случае, если столбец добавлен по ошибке, а затем его необходимо удалить через некоторое время, просто создайте новую миграцию, чтобы удалить лишний столбец. Моя основная причина этого в том, что работая в команде, вы не хотите, чтобы вашим коллегам приходилось перестраивать свои базы данных с нуля. При таком простом подходе вы (и они) можете продолжать работать итеративно.
Кстати, при создании новой базы данных с нуля (без каких-либо данных) миграции, как правило, выполняются очень быстро. В проекте, над которым я сейчас работаю, есть 177 миграций, это не вызывает проблем при создании новой базы данных.
Хотя я уверен, что у каждого есть свои методы, существует несколько правил, подразумеваемых тем, как работает система миграции:
- Никогда не фиксируйте изменения в миграциях, которые могли быть использованы другими разработчиками или предыдущие развертывания. Вместо этого сделайте дополнительную миграцию, чтобы настроить вещи по мере необходимости.
- Никогда не помещайте зависимости на уровне модели в миграцию. В какой-то момент в будущем модель может быть переименована или удалена, что предотвратит миграцию. Сохраняйте миграцию как можно более автономной, даже если это означает, что она довольно упрощенная и низкоуровневая.
Конечно, есть исключения. Например, если миграция не работает по какой-либо причине, может потребоваться исправление для ее обновления. Однако даже в этом случае характер изменений, вызванных миграцией, не должен измениться, хотя их реализация может быть возможна.
Любой зрелый проект Rails, вероятно, будет иметь от 200 до 1000 миграций. По моему опыту, необычно видеть проект, в котором меньше 30 человек, за исключением стадии планирования. В конце концов, каждой модели обычно нужен свой собственный файл миграции.
Свертывание нескольких миграций в одну - плохая привычка при работе над развивающейся частью программного обеспечения. Вы, вероятно, не сворачиваете свою историю системы управления версиями, так что зачем беспокоиться об истории схемы базы данных?
Единственный случай, когда я могу рассматривать ее как достаточно практичную, - это если вы разветвляете старый проект для создания новой версии или создания новой версии. выключены и не хотят переносить огромное количество миграций.
По моему опыту, необычно видеть проект, в котором меньше 30 человек, за исключением стадии планирования. В конце концов, каждой модели обычно нужен свой собственный файл миграции.Свертывание нескольких миграций в одну - плохая привычка при работе над развивающейся частью программного обеспечения. Вы, вероятно, не сворачиваете свою историю системы управления версиями, так что зачем беспокоиться об истории схемы базы данных?
Единственный случай, когда я могу рассматривать ее как достаточно практичную, - это если вы разветвляете старый проект для создания новой версии или создания новой версии. выключены и не хотят переносить огромное количество миграций.
По моему опыту, необычно видеть проект, в котором меньше 30 человек, за исключением стадии планирования. В конце концов, каждой модели обычно нужен свой собственный файл миграции.Свертывание нескольких миграций в одну - плохая привычка при работе над развивающейся частью программного обеспечения. Вы, вероятно, не сворачиваете свою историю системы управления версиями, так что зачем беспокоиться об истории схемы базы данных?
Единственный случай, когда я могу рассматривать ее как достаточно практичную, - это если вы разветвляете старый проект для создания новой версии или создания новой версии. выключены и не хотят переносить огромное количество миграций.
Свертывание нескольких миграций в одну - плохая привычка при работе над развивающейся частью программного обеспечения. Вы, вероятно, не сворачиваете свою историю системы управления версиями, так что зачем беспокоиться об истории схемы базы данных?
Единственный случай, когда я могу рассматривать ее как достаточно практичную, - это если вы разветвляете старый проект для создания новой версии или создания новой версии. выключены и не хотят переносить огромное количество миграций.
Свертывание нескольких миграций в одну - плохая привычка при работе над развивающейся частью программного обеспечения. Вы, вероятно, не сворачиваете свою историю системы управления версиями, так что зачем беспокоиться об истории схемы базы данных?
Единственный случай, когда я могу рассматривать ее как достаточно практичную, - это если вы разветвляете старый проект для создания новой версии или создания новой версии. выключены и не хотят переносить огромное количество миграций.
Большое количество миграций - это хорошо. В сочетании с вашей системой контроля версий они позволяют вам увидеть, какой разработчик внес изменения в базу данных и почему. Это помогает с подотчетностью. Удаление их просто создает большую проблему.
Если вы действительно хотите быстро запустить новую базу данных, вы можете просто загрузить схему с помощью rake db: schema: load RAILS_ENV = your_environment и, если вы хотите получить свою тестовую базу данных быстро настроить, вы можете просто использовать rake db: test: prepare
При этом, если вы действительно хотите консолидировать свои миграции, я бы создал новую миграцию, которая проверяет, была ли выполнена последняя миграция в вашем наборе (например: существует ли добавленный вами столбец?), а если нет, он сработает. В противном случае миграция просто добавится в таблицу схемы как завершенная, поэтому она не будет '
В верхней части schema.rb объявляется:
# This file is auto-generated from the current state of the database. Instead of editing this file,
# please use the migrations feature of Active Record to incrementally modify your database, and
# then regenerate this schema definition.
#
# 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 to check this file into your version control system.
Я должен подтвердить то, что [giorgian] сказал выше о различных миграциях для разных целей. Я рекомендую очистить миграции, ориентированные на разработку, вместе с другими задачами, которые вы выполняете при переходе к выпуску. Это хорошо работает для меня, для меня и небольших команд. Конечно, мое основное приложение находится поверх и между двумя другими базами данных с их собственными схемами, с которыми я должен быть осторожен, поэтому мы используем миграции (а не восстановление схемы) для новой установки, и те, которые должны пережить разработку релиза.