Каковы некоторые стратегии для поддержки общей схемы базы данных с командой разработчиков и без администратора базы данных?

Question

Мне интересно, как другие подошли к проблеме поддержки и синхронизации изменений базы данных у многих (более 10) разработчиков без администратора базы данных? По сути, я имею в виду, что если кто-то хочет внести изменения в базу данных, какие существуют стратегии для этого? (то есть я создал модель 'Car' и теперь хочу применить соответствующий DDL к базе данных и т. д.)

Мы в первую очередь магазин Python, а наш ORM - это SQLAlchemy. Ранее мы писали наши модели таким образом, чтобы создавать модели с использованием нашего ORM, но недавно мы отказались от этого, потому что:

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

Наше решение этой проблемы состояло в том, чтобы в основном иметь «привратника», который проверяет каждое изменение в базе данных и применяет все принятые изменения базы данных в файл accepted_db_changes.sql, в результате чего разработчики, которым необходимо внести какие-либо изменения в базу данных, отправляют свои запросы в файл proposed_db_changes.sql. Мы регистрируем этот файл и, когда он обновляется, мы все применяем изменения в нашей личной базе данных на нашей машине для разработки. Мы не создаем индексы или ограничения для моделей, они явно применяются к базе данных.

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

Спасибо!

Answer 1

Решение скорее административное, чем техническое :)

Общее правило простое, в проекте должны быть только древовидные зависимости: - Всегда должен быть один главный источник схемы, который хранится вместе с исходным кодом проекта в системе управления версиями. - Все, что затронуто изменением в главном источнике, должно автоматически генерироваться каждый раз при обновлении главного источника, никакое ручное вмешательство не допускается никогда, если автоматическая генерация не работает - исправьте основной источник или генератор, не обновляйте вручную исходный код - Все повторные генерации должны выполняться одним и тем же человеком, который обновил главный источник, и все изменения, включая изменение основного источника, должны рассматриваться как одна транзакция (один контроль источника, одна сборка / развертывание для каждой уязвимой среды, включая обновление БД)

При принудительном исполнении это дает 100% надежный результат.

Существует, по сути, 3 возможных варианта основного источника 1) Метаданные БД, источники генерируются после обновления БД каким-либо инструментом, подключающимся к работающей БД 2) Исходный код, какой-то инструмент генерирует схему SQL из источников, аннотируется особым образом, а затем SQL запускается на БД 3) DDL, схема SQL и исходный код генерируются каким-либо инструментом 4) используется другое описание (например, текстовый файл, читаемый специальным скриптом Perl, генерирующим как схему SQL, так и исходный код)

1,2,3 одинаково хороши при условии, что необходимый вам инструмент существует и не слишком дорогой 4 - это универсальный подход, но его следует применять с самого начала проекта, и он требует дополнительных затрат в несколько тысяч строк кода на незнакомом языке для поддержки

Answer 2

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

Его система ожидает, что у каждого разработчика будет своя собственная копия базы данных, а также некоторая общая тестовая база данных, используемая до развертывания в производство. Ваша ситуация - одна из самых простых ситуаций, описанных в книге, поскольку у вас нет нескольких отдельных приложений, использующих базу данных (хотя вам нужен кто-то, кто знает, как описать миграцию базы данных). Самое главное - иметь возможность создавать базу данных из информации в системе контроля версий и иметь изменения, описанные небольшими миграциями (см. Ответ @ WoLpH), а не просто вносить изменения в базу данных. Также вам будет проще, если у вас есть хотя бы тесты базы данных ORM <->, чтобы убедиться, что они все еще синхронизированы.

Answer 3

Так что я прав, предполагая, что вы проектируете свой БД непосредственно на физическом БД? Раньше я делал это много лет назад, но качество получаемой базы было довольно плохим. Если вы используете инструмент моделирования (лично я думаю, что Sybase pdesigner все еще лучший в своем роде, но посмотрите вокруг), каждый может внести изменения в модель и просто синхронизировать свои локальные базы данных по мере необходимости (он также подберет задачи документации). Итак, пост Боба, мастер - это модель pdesigner, а не физическая база данных.

Является ли ваш accepted_db_changes.sql файл одним огромным списком сценариев изменений? Я не уверен, что мне нравится идея изменения имени файла и т. Д. Учитывая, что разница между двумя версиями БД представляет собой последовательный список сценариев изменения, как насчет такой модели:

Ver1 (folder)
  Change 1-1.sql
  Change 1-2.sql
  Change 1-3.sql
Ver2 (folder)
  Change 2-1.sql
  Change 2-2.sql
  Change 2-3.sql

Где каждое изменение (новый файл) проверяется перед фиксацией.

Общее правило должно заключаться в том, чтобы сознательно пытаться автоматизировать как можно большую часть развертывания БД в ваших средах разработки; мы демонстративно получили окупаемость инвестиций в эту работу. Вы можете использовать такие инструменты, как redgate для генерации вашего ddl (у него есть API, хотя он не уверен, работает ли он с SQLAlchemy). IMO, изменения БД должны быть тривиальными, если вы обнаружите, что они блокируют, посмотрите, что вы можете автоматизировать.

Answer 4

Вы пробовали SQLalchemy Migrate инструменты?

Они специально разработаны для автоматической миграции изменений в дизайне вашей базы данных.