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

Видеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть некоторые обсуждения этой темы в вики Django.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для 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

Thanks to stackoverflow users I could write this quick script to find structure differences.

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: --------