Вы помещаете свои индексы в систему контроля версий?

Question

А как вы поддерживаете их синхронизацию между тестовой и производственной средами?

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

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

Я периодически проверяю статистику индекса и удаляю ненужные индексы. Я обычно делаю это, создавая скрипт удаления, который затем копирую обратно в другие среды.

Но кое-где индексы создаются и удаляются вне обычного процесса, и действительно трудно понять, в чем различия.

Я нашел одну вещь, которая действительно помогает, - это использовать простые числовые индексные имена, такие как

idx_t_01
idx_t_02

где t - краткое сокращение таблицы. Я считаю, что обслуживание индекса невозможно, когда я пытаюсь разобраться со всеми задействованными столбцами, например,

idx_c1_c2_c5_c9_c3_c11_5

Слишком сложно дифференцировать подобные индексы.

Есть ли у кого-нибудь действительно хороший способ интегрировать ведение индексов в систему контроля версий и жизненный цикл разработки?

Answer 1

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

При создании версий схемы было множество других тем.

Answer 2

Полная схема для вашей базы данных должна находиться в системе контроля версий рядом с вашим кодом. Когда я говорю «полная схема», я имею в виду определения таблиц, запросы, хранимые процедуры, индексы и многое другое.

Когда вы делаете новую установку, вы делаете: - проверить версию X продукта. - из каталога «база данных» вашей кассы запустите сценарий (и) базы данных, чтобы создать базу данных. - используйте кодовую базу из вашей кассы для взаимодействия с базой данных.

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

При таком подходе у вас никогда не возникает проблем с синхронизацией базы данных кода.

Answer 3

Да, любые Изменения DML или DDL записываются в сценарии и возвращаются в систему управления версиями, в основном путем миграции активных записей в рельсах. Я ненавижу постоянно грызть рога рельсов, но за многие годы построения систем на базе DB я считаю, что путь миграции намного лучше, чем любая домашняя система, которую я использовал или построил.

Однако я называю все свои индексы (не позволяйте СУБД придумать какое-нибудь сумасшедшее имя, которое она выберет). Не префиксируйте их , это глупо (потому что у вас есть метаданные типа в sysobjects или в любой другой вашей БД), но я включаю имя таблицы и столбцы, например, tablename_col1_col2.

Таким образом, если я просматриваю системные объекты, я могу легко увидеть индексы для конкретной таблицы (также это обычная привычка, когда-то на некоторых дБМС, которые я использовал, имена индексов были уникальными во всей БД, поэтому единственный способ обеспечить это - использовать уникальные имена).

Answer 4

Я думаю, что здесь есть две проблемы: соглашение об именовании индекса и добавление изменений базы данных в ваш источник управления / жизненный цикл. Я займусь последним вопросом.

Я давно программист на Java, но недавно был представлен системе, которая использует Ruby on Rails для доступа к базе данных для части системы. Одна вещь, которая мне нравится в RoR, это понятие «миграции». По сути, у вас есть каталог, полный файлов, которые выглядят как 001_add_foo_table.rb, 002_add_bar_table.rb, 003_add_blah_column_to_foo.rb и т. Д. Эти исходные файлы Ruby расширяют родительский класс, переопределяя методы, называемые «вверх» и «вниз». Метод «up» содержит набор изменений базы данных, которые необходимо внести, чтобы перенести предыдущую версию схемы базы данных в текущую версию. Точно так же метод «down» возвращает изменение к предыдущей версии. Когда вы хотите установить схему для конкретной версии, сценарии миграции Rails проверяют базу данных, чтобы увидеть текущую версию, а затем находят файлы .rb, которые поднимают вас туда (или вниз) до нужной ревизии.

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

Здесь нет ничего особенного или особенного в Rails, просто я впервые увидел эту технику широко используемой. Вы также можете использовать пары файлов DDL SQL, например, 001_UP_add_foo_table.sql и 001_DOWN_remove_foo_table.sql. Остальное - небольшой вопрос написания сценариев оболочки, упражнение, оставленное читателю.

Answer 5

При использовании приложения Grails индексы по умолчанию сохраняются в системе управления версиями, поскольку вы определяете определение индекса внутри файла, который представляет объект вашего домена. Просто предлагая перспективу «Грааля» в качестве FYI.

Answer 6

В моем текущем проекте у меня есть две вещи в управлении исходным кодом - полный дамп пустой базы данных (используя pg_dump -c, чтобы у него были все ddl для создания таблиц и индексов) и скрипт, который определяет, какая версия базы данных у вас есть, и применяет изменения / капли / добавления, чтобы привести его к текущей версии. Первый запускается при установке на новом сайте, а также когда QA начинает новый цикл тестирования, а второй запускается при каждом обновлении. Когда вы вносите изменения в базу данных, вам необходимо обновить оба этих файла.

Answer 7

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

Относительно того, относятся ли они к управлению исходным кодом, я не совсем уверен.

Answer 8

Я всегда использую исходный код SQL (DDL, DML и т. Д.). Его код, как и любой другой. Это хорошая практика.

Answer 9

Я помещаю свои индексы не в систему контроля версий, а в скрипт создания индексов. ; -)

Index-именование:

• IX_CUSTOMER_NAME для поля «имя» в таблице «клиент»
• PK_CUSTOMER_ID для первичного ключа,
• UI_CUSTOMER_GUID, для поля GUID клиента, которое является уникальным (следовательно, "UI" - уникальный индекс).