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

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

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

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

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

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

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

Индекс-именование:

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

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

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

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

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

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

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

Что касается того, принадлежат ли они к системе контроля версий, я не совсем уверен.

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

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

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

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

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

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