Как вы готовите свои дельта SQL? вы вручную сохраняете каждый изменяющий схему SQL в дельта-папку или у вас есть какой-то автоматизированный процесс?
Мне интересны соглашения для схемы базы данных версий вместе с исходным кодом. Может быть, перехват фиксации, который отличается схемой?
Кроме того, какие варианты для разных дельт существуют помимо DbDeploy?
EDIT:, видя ответы, я хотел бы уточнить, что я знаком со стандартной схемой для запуска миграции базы данных с использованием дельт. Мой вопрос заключается в создании самих дельт, предпочтительно автоматически.
Кроме того, версия для PHP и MySQL, если это имеет значение. (Нет Ruby-решений, пожалуйста).
См
Есть ли система управления версиями для изменений структуры базы данных?
Как мне изменить базу данных MS SQL в SVN?
и статья Джеффа
Получите свою базу данных в разделе Контроль версий
Я чувствую твою боль, и я хочу, чтобы был лучший ответ. Это может быть ближе к тому, что вы искали.
Механизмы отслеживания изменений схемы БД
Как правило, я чувствую, что нет адекватного, приемлемого решения для этого, и я откатываюсь в этой области.
Вы можете взглянуть на другой похожий поток: Как мне изменить базу данных MS SQL в SVN?.
Если вы все еще ищете варианты: посмотрите на конструктор neXtep. Это бесплатная среда разработки баз данных GPL, основанная на концепциях управления версиями. В среде вы всегда работаете с версиями объектов и можете сосредоточиться на разработке модели данных. Как только релиз будет завершен, механизм генерации SQL, подключенный к системе управления версиями, может генерировать любую дельта, которая вам нужна между двумя версиями, и предложит вам какой-то механизм доставки, если вам нужно.
Кроме всего прочего, вы можете синхронизировать и реверсировать синхронизацию своей базы данных во время разработки, создавать диаграммы модели данных, запрашивать свою базу данных с помощью интегрированных SQL-клиентов и т.д.
Посмотрите на wiki для получения дополнительной информации: http://www.nextep-softwares.com/wiki
В настоящее время он поддерживает Oracle, MySql и PostgreSql и находится в java, поэтому продукт работает на Windows, Linux и Mac.
Я не управляю дельтами. Я вношу изменения в основную базу данных и имею инструмент, который создает сборку на основе XML script на основе основной базы данных.
Когда придет время для обновления существующей базы данных, у меня есть программа, которая использует построенную на основе XML конструкцию script для создания новой базы данных и голых таблиц. Затем я копирую данные из старой базы данных с помощью INSERT INTO x SELECT FROM y, а затем применяю все индексы, ограничения и триггеры.
Новые таблицы, новые столбцы, удаленные столбцы обрабатываются автоматически и с несколькими небольшими трюками для настройки подпрограммы копирования. Я могу обрабатывать переименования столбцов, изменения типа столбца и другие базовые рефакторинги.
Я бы не рекомендовал это решение в базе данных с огромным количеством данных, но я регулярно обновляю базу данных объемом более 1 ГБ с 400 таблицами.
Вы не указали, какие RDBMS вы используете, но если это MS SQL Server, Red-Gate SQL Compare был незаменим для нас в создании дельт между скриптами создания объектов.
Я не собираюсь использовать собственный рожок, но я разработал внутреннее веб-приложение для отслеживания изменений в схемах базы данных и создания сценариев обновленных версий.
Этот инструмент называется Brazil и теперь является открытым исходным кодом под лицензией MIT. Бразилия является рубином/рубином на основе рельсов и поддерживает развертывание изменений в любой базе данных, что Ruby DBI поддерживает (MySQL, ODBC, Oracle, Postgres, SQLite).
Планируется поддержка размещения сценариев обновления в управлении версиями.
http://bitbucket.org/idler/mmp - инструмент для управления версиями для mysql, написанный на PHP
Я уверен, что изменения схемы всегда аддитивны. Поэтому я не отбрасываю столбцы и таблицы, потому что это задержит данные и не будет отменено позже. Таким образом, код, который использует базу данных, может быть откат без потери данных или функциональности.
У меня есть миграция script, которая содержит инструкции, которые создают таблицы и столбцы, если они еще не существуют и заполняют их данными.
Миграция script выполняется всякий раз, когда производственный код обновляется и после новых установок.
Когда я хочу что-то отбросить, я делаю это, удаляя их из базы данных install script и миграции script, чтобы эти устаревшие элементы схемы постепенно прекращались в новых установках. С недостатком, что новые установки не могут перейти на более раннюю версию перед установкой.
И, конечно же, я запускаю DDL через эти сценарии и никогда не попадаю непосредственно в базу данных, чтобы синхронизировать ситуацию.
Мы экспортируем данные в переносимый формат (используя нашу инструментальную цепочку), а затем импортируем его в новую схему. нет необходимости в дельта-SQL. Очень рекомендуется.
Меня тоже интересует эта тема.
Есть некоторые обсуждения по этой теме в вики Django.
Интересно, что это выглядит как CakePHP имеет встроенную версию управления версиями, используя только команду cake schema generate.
Я использую Firebird для большинства разработок, и я использую FlameRobin для этого. Он имеет хороший вариант для регистрации всех изменений. Он может записывать все в один большой файл или один файл на изменение базы данных. Я использую этот второй вариант, а затем я храню каждый script в программном обеспечении для управления версиями - ранее я использовал Subversion, теперь я использую Git.
Я предполагаю, что вы можете найти некоторый инструмент MySQL, который имеет ту же функцию ведения журнала, что и FlameRobin для Firebird.
В одной из таблиц базы данных я сохраняю номер версии структуры базы данных, поэтому я могу легко обновлять любую базу данных. Я также написал простой PHP script, который выполняет эти SQL-скрипты один за другим в любой целевой базе данных (путь к базе данных и имя пользователя/пароль предоставляются в командной строке).
Также существует возможность регистрировать все операторы DML (insert, update delete), и я активирую их при изменении некоторых данных по умолчанию, которые содержатся в каждой базе данных.
Я написал хороший белый документ о том, как я все это подробно расскажу. Вы можете загрузить документ в формате .pdf вместе с демонстрационными PHP-скриптами из здесь.
Я также разработал набор PHP-скриптов, где разработчики могут отправлять свои сценарии deltasql в центральный репозиторий.
В одной из таблиц базы данных (называемой TBSYNCHRONIZE) я сохраняю номер версии последнего выполненного script, поэтому я могу легко обновлять любую базу данных с помощью веб-интерфейса или клиента, специально разработанного для Eclipse.
Веб-интерфейс позволяет управлять несколькими проектами. Он поддерживает также "ветки" базы данных.
Вы можете протестировать приложение на http://www.gpu-grid.net/deltasql (если вы входите в систему как admin с паролем testdbsync). Приложение является открытым исходным кодом и может быть загружено здесь: http://sourceforge.net/projects/deltasql
deltasql используется продуктивно в Швейцарии и Индии и пользуется популярностью в Японии.
Несколько месяцев назад я искал инструмент для управления версиями MySQL. Я нашел много полезных инструментов, таких как миграция Doctrine, миграция RoR, некоторые инструменты записываются в Java и Python.
Но никто из них не удовлетворил мои требования.
Мои требования:
Я начал писать свой инструмент миграции, и сегодня у меня есть бета-версия.
Пожалуйста, попробуйте, если у вас есть интерес к этой теме. Пожалуйста, пришлите мне будущие запросы и сообщения об ошибках.
Исходный код: bitbucket.org/idler/mmp/src Обзор на английском языке: bitbucket.org/idler/mmp/wiki/Home Обзор по-русски: antonoff.info/development/mysql-migration-with-php-project
Я использую http://code.google.com/p/oracle-ddl2svn/
Когда я приземляюсь на новую БД:
Во-первых, я проверяю структуру:
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 я мог бы написать этот быстрый script, чтобы найти различия в структуре.
src: fooobar.com/questions/17566/... и fooobar.com/questions/8481/...
На втором этапе я проверяю данные, таблицу за таблицей mysqldiff. Это немного архаично, но php-контур на основе information_schema datas делает работу уверенно
Для управления версиями я использую то же самое, но я форматирую обновление SQL script (для обновления или отката) с результатами diff, и я использую условное обозначение номера версии (с несколькими модификациями номер версии выглядит как 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/
в зависимости от интереса, продолжит писать больше.