Каковы некоторые стратегии поддержания схемы общей базы данных с командой разработчиков и никакого DBA?
Мне любопытно на предмет того, как другие приблизились к проблеме поддержания и синхронизации изменений базы данных через многих (10 +) разработчики без DBA? То, что я имею в виду, в основном, то, что, если кто-то хочет внести изменение в базу данных, что некоторые стратегии к выполнению этого? (т.е. я создал модель 'Car', и теперь я хочу применить соответствующий DDL к базе данных и т.д.)
Мы - прежде всего, магазин Python, и наш ORM является SQLAlchemy. Ранее, мы записали наши модели таким способом создать модели с помощью нашего ORM, но мы недавно угробили это потому что:
- Мы не могли отследить изменения с помощью ORM
- Состояние ORM не было в синхронизации с базой данных (например, много различий, прежде всего, связанных с индексами и ограничениями на уникальность данных)
- Не было никакого пути к изменениям базы данных аудита, если разработчик не зарегистрировал изменение базы данных по электронной почте в команде.
Наше решение этой проблемы состояло в том, чтобы в основном иметь человека "привратника", который проверяет каждое изменение в базе данных и применяет все принятые изменения базы данных в accepted_db_changes.sql файл, посредством чего разработчики, которые должны внести любые изменения базы данных, помещают свои запросы в a proposed_db_changes.sql файл. Мы регистрируем этот файл, и, когда он обновляется, все мы применяем изменение в нашей персональной базе данных по нашей машине разработки. Мы не создаем индексы или ограничения на модели, они применяются явно на базе данных.
Я хотел бы знать то, что является некоторыми стратегиями поддержать схемы базы данных, и, если наш кажется разумным.
Спасибо!
4 ответа
Решение скорее административное, чем техническое :)
Общее правило простое, в проекте должны быть только древовидные зависимости: - Всегда должен быть один мастер-источник схемы, хранящийся вместе с исходным кодом проекта в системе контроля версий. - Все, на что влияют изменения в мастер-источнике, должно автоматически перегенерироваться каждый раз, когда мастер-источник обновляется, никакое ручное вмешательство не допускается никогда, если автоматическая генерация не работает - исправьте либо мастер-источник, либо генератор, не обновляйте исходный код вручную. - Все повторныепоколения должны выполняться тем же человеком, который обновил мастер-источник, и все изменения, включая изменение мастер-источника, должны рассматриваться как одна транзакция (один коммит контроля исходного кода, одна сборка/развертывание для каждой затронутой среды, включая обновление БД)
Если это соблюдается, это дает 100% надежный результат.
По сути, существует 3 возможных варианта выбора главного источника 1) Метаданные БД, источники генерируются после обновления БД каким-либо инструментом, подключающимся к живой БД 2) Исходный код, некий инструмент генерирует SQL схему из исходных данных, аннотированных специальным образом, а затем SQL запускается на БД 3) DDL, и схема SQL, и исходный код генерируются каким-либо инструментом 4) используется какое-то другое описание (скажем, текстовый файл, читаемый специальным Perl-скриптом, генерирующим и схему SQL, и исходный код)
1,2,3 одинаково хороши, при условии, что нужный вам инструмент существует и не слишком дорог. 4 - универсальный подход, но он должен применяться с самого начала проекта и требует поддержки нескольких тысяч строк кода на незнакомом языке
.Пробовали ли вы инструменты SQLalchemy Migrate ?
Они специально разработаны для автоматической миграции изменений структуры вашей базы данных.
Правильно ли я предполагаю, что вы проектируете свою базу данных непосредственно на физической базе данных? Я делал это много лет назад, но качество результирующей базы данных было довольно низким. Если вы используете инструмент моделирования (лично я считаю, что Sybase pdesigner по-прежнему является лучшим в своем классе, но посмотрите вокруг), каждый может внести изменения в модель и просто синхронизировать свои локальные базы данных по мере необходимости (он также будет выполнять задачи по документации). Итак, повторяя пост Боба, мастер - это модель pdesigner, а не физическая база данных.
Является ли ваш файл accept_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). ИМО, изменения БД должны быть тривиальными, если вы обнаружите, что они блокируют, посмотрите, что вы можете автоматизировать.
Вам может быть полезна книга Refactoring Databases, поскольку она содержит общие стратегии управления базами данных, а не только способы их рефакторинга.
Его система предполагает, что каждый разработчик будет иметь свою собственную копию базы данных, а также некоторую общую тестовую базу данных, используемую перед развертыванием в производство. Ваша ситуация - одна из самых простых ситуаций, описанных в книге, поскольку у вас нет множества отдельных приложений, использующих базу данных (хотя вам нужен человек, который знает, как описать миграцию базы данных). Самое главное - уметь создавать базу данных на основе информации в системе контроля исходных текстов и иметь возможность описывать изменения с помощью небольших миграций (см. ответ @WoLpH), а не просто вносить изменения в базу данных. Также вам будет проще, если у вас есть хотя бы тесты ORM <-> база данных, чтобы проверить, что они все еще синхронизированы.