Как вы редактируете схему своей базы данных? [закрыто]

Как вы готовите дельты SQL? вы вручную сохраняете каждый SQL-запрос, изменяющий схему, в дельта-папку, или у вас есть какой-то автоматический процесс сравнения?

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

Кроме того, какие существуют возможности для различения дельт помимо DbDeploy ?

РЕДАКТИРОВАТЬ: увидев ответы, я хотел бы уточнить, что я знаком со стандартной схемой выполнения миграции базы данных с использованием дельт. У меня вопрос о создании самих дельт, желательно автоматически.

Кроме того, управление версиями предназначено для PHP и MySQL, если это имеет значение. (Пожалуйста, не используйте Ruby).

Видеть

Есть ли система контроля версий для изменения структуры базы данных?

Как мне изменить версию моей базы данных MS SQL в SVN?

и статья Джеффа

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

Я чувствую твою боль и желаю лучшего ответа. Возможно, это ближе к тому, что вы искали.

Механизмы отслеживания изменений схемы БД

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

Вы можете взглянуть на другую похожую тему: Как мне изменить версию моей базы данных MS SQL в SVN? ,

Если вы все еще ищете варианты: взгляните на дизайнер neXtep. Это бесплатная среда разработки баз данных GPL, основанная на концепции контроля версий. В среде вы всегда работаете с версионными сущностями и можете сосредоточиться на разработке модели данных. После завершения выпуска механизм генерации SQL, подключенный к системе контроля версий, может сгенерировать любую необходимую вам дельту между двумя версиями и предложит вам некоторый механизм доставки, если вам нужно.

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

Загляните в вики для получения дополнительной информации: http://www.nextep-softwares.com/wiki

В настоящее время он поддерживает Oracle, MySql и PostgreSql и находится на java, поэтому продукт работает в Windows, Linux и Mac.

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

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

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

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

И, конечно же, я выполняю DDL через эти сценарии, а не непосредственно в базе данных, чтобы все было синхронизировано.

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

Когда приходит время обновить существующую базу данных, у меня есть программа, использующая сценарий сборки на основе XML для создания новой базы данных и пустых таблиц. Затем я копирую данные из старой базы данных, используя INSERT INTO x SELECT FROM y, а затем применяю все индексы, ограничения и триггеры.

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

Я бы не рекомендовал это решение для базы данных с огромным объемом данных, но я регулярно обновляю базу данных размером более 1 ГБ с 400 таблицами.

Вы не упомянули, какую СУБД вы используете, но если это MS SQL Server, Red-Gate SQL Compare незаменим при создании дельт между сценариями создания объектов.

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

Этот инструмент называется Brazil и теперь имеет открытый исходный код по лицензии MIT. Brazil основан на ruby ​​/ ruby ​​on rails и поддерживает развертывание изменений в любой базе данных, поддерживаемой Ruby DBI (MySQL, ODBC, Oracle, Postgres, SQLite).

Планируется поддержка включения скриптов обновления в систему контроля версий.

http://bitbucket.org/idler/mmp - инструмент управления версиями схемы для mysql, написанный на PHP

Мы экспортируем данные в переносимый формат (используя нашу инструментальную цепочку), а затем импортируем их в новую схему. нет необходимости в дельта-SQL. Настоятельно рекомендуется.

Я использую базу данных Firebird для большей части разработки, и я использую для нее инструмент администрирования FlameRobin . У него есть хорошая возможность регистрировать все изменения. Он может записывать все в один большой файл или один файл на каждое изменение базы данных. Я использую этот второй вариант, а затем сохраняю каждый сценарий в программе контроля версий - раньше я использовал Subversion, теперь я использую Git.

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

В одной из таблиц базы данных я храню номер версии структуры базы данных, поэтому я могу легко обновить любую базу данных. Я также написал простой сценарий PHP, который выполняет эти сценарии SQL один за другим в любой целевой базе данных (путь к базе данных и имя пользователя / пароль указываются в командной строке).

Также есть возможность регистрировать все операторы DML (вставка, обновление, удаление), и я активирую это, изменяя некоторые данные «по умолчанию», содержащиеся в каждой базе данных.

Я написал красивую белую книгу о том, как я все это делаю в деталях. Вы можете скачать статью в формате .pdf вместе с демонстрационными PHP-скриптами отсюда .

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

В одной из таблиц базы данных (называемой TBSYNCHRONIZE) я храню номер версии последнего выполненного скрипта, поэтому я могу легко обновить любую базу данных с помощью веб-интерфейса или клиента, специально разработанного для Eclipse.

Веб-интерфейс позволяет управлять несколькими проектами. Он поддерживает также «филиалы» базы данных.

Вы можете протестировать приложение на http://www.gpu-grid.net/deltasql (если вы войдете в систему как администратор с паролем testdbsync). Приложение с открытым исходным кодом, его можно скачать здесь: http://sourceforge.net/projects/deltasql

deltasql продуктивно используется в Швейцарии и Индии и популярен в Японии.

Несколько месяцев назад я искал инструмент для управления версиями схемы MySQL. Я нашел много полезных инструментов, таких как миграция Doctrine, миграция RoR, некоторые инструменты, написанные на Java и Python.

Но ни один из них не удовлетворил мои требования.

Мои требования:

1. Нет требований, кроме PHP и MySQL
2. Нет файлов конфигурации схемы, таких как schema.yml в Doctrine.
3. Возможность читать текущую схему из соединения и создавать новый сценарий миграции, чем представлять идентичную схему в других установках приложения.

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

Пожалуйста, попробуйте, если вам интересна эта тема. Пожалуйста, присылайте мне будущие запросы и отчеты об ошибках.

Исходный код: bitbucket.org/idler/mmp/src Обзор на английском языке: bitbucket.org/idler/mmp/wiki/ Домашний обзор на русском языке: antonoff.info/development/mysql-migration-with-php-project

Я использую http://code.google.com/p/oracle-ddl2svn/

Меня тоже интересует эта тема.

На эту тему есть обсуждения в вики Django .

Интересно, что похоже, что CakePHP имеет встроенное управление версиями схемы, использующее только cake schema generateкоманду.

Для MySQL

Когда я попадаю в новую БД:

Сначала проверяю структуру:

mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql
mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql
diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt
cat DIFF_FILENAME.txt | less

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

src: https://stackoverflow.com/a/8718572/4457531 и https://stackoverflow.com/a/26328331/4457531

На втором этапе я проверяю данные таблица за таблицей с помощью mysqldiff. Это немного архаично, но цикл php, основанный на information_schemaданных, безусловно, работает

Для управления версиями я использую тот же способ, но я форматирую сценарий обновления SQL (для обновления или отката) с результатами сравнения и использую соглашение о номере версии (с некоторыми изменениями номер версии выглядит как IP-адрес) .

initial version : 1.0.0
                  ^ ^ ^
                  | | |
structure change: - | |
datas added: -------- |
datas updated: --------

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

Вот полная реализация для SQL Server (при необходимости такое же решение можно разработать для MySQL): Как поддерживать версию схемы базы данных SQL Server

После долгого расследования я выяснил, что есть некоторые сторонние инструменты или типы проектов Visual Studio, которые меня не устраивают, или просто блоги о теории, но без реализации. Итак, я внедрил рабочую систему, которая используется почти год, и объяснил здесь:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

в зависимости от интереса, продолжу писать дальше.