Насколько корректно отслеживать изменение структуры базы данных SVN?

Основная проблема - это версия структуры базы данных.

Стандартные утилиты mysqldump и pg_dump не создают файлы, хорошо подходящие для управления версиями.

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

PostgreSQL Diff

 --
--- TOC entry 2630 (class 0 OID 0)
+-- TOC entry 2549 (class 0 OID 0)
 -- Dependencies: 6
 -- Name: SCHEMA adm; Type: COMMENT; Schema: -; Owner: admin
@@ -61,5 +61,5 @@

MySQL Diff

--- Dump completed on 2010-07-20 14:33:44
+-- Dump completed on 2010-08-11  8:59:39
Index: /db.sql
===================================================================
--- /db.sql (revision 1274)
+++ /db.sql (revision 1317)
@@ -36,5 +36,5 @@
   `message` text,
   PRIMARY KEY  (`id`)
-) ENGINE=MyISAM AUTO_INCREMENT=21122 DEFAULT CHARSET=utf8;
+) ENGINE=MyISAM AUTO_INCREMENT=23730 DEFAULT CHARSET=utf8;

Любые предложения / ссылки / утилиты по лучшему способу контроля версий приветствуются!

Спасибо.


person Igor    schedule 30.08.2010    source источник


Ответы (5)


Взгляните на LiquiBase (http://www.liquibase.org/)

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

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

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

person Marty Pitt    schedule 30.08.2010
comment
Отличный совет. Я искал решение с открытым исходным кодом для управления версиями базы данных. - person Lèse majesté; 30.08.2010
comment
Спасибо за совет. Искал такой инструмент. - person Igor; 03.09.2010

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

Это не идеальная система, но до сих пор она работала у нас достаточно хорошо.

person Mark    schedule 30.08.2010
comment
Это тот же метод, который мы используем во многих проектах, он хорошо работает для нас, за исключением, возможно, некоторых разработчиков, которые жалуются на необходимость написания sql для создания таблиц. Я обычно говорю им, что им все равно не следует полагаться на дизайнеров (даже если они сэкономят время). - person Zachary Yates; 30.08.2010
comment
Я согласен. Если разработчик собирается работать с базами данных, он должен иметь возможность писать сценарии создания таблиц с нуля, не задействуя слишком много ячеек мозга. Если они не могут, может быть, им стоит передать работу с базой данных кому-то более квалифицированному. При этом у меня нет никаких проблем с тем, чтобы кто-то использовал любой инструмент, который им нравится, чтобы собрать сценарий, но в конце концов, он либо проверен на подрывную деятельность, либо не развертывается. - person Mark; 30.08.2010
comment
Абсолютно согласен с вами, ребята, даже если мы иногда все еще полагаемся на IDE. Спасибо за совет! - person Igor; 03.09.2010

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

Для небольших проектов у меня обычно есть файл с именем install.sql, содержащий все мои CREATE операторы, и schema.txt, который описывает схему. Для более крупных проектов вы можете использовать что-то вроде dbForge, которое позволяет управлять версиями схемы базы данных в профессиональной версии, хотя это немного дорого, если это все, для чего вы его используете.

Ознакомьтесь с этой статьей на Coding Horror (особенно по первой ссылке в этом посте) для получения дополнительных указаний.

person Lèse majesté    schedule 30.08.2010
comment
Спасибо, Лезе! Проверял эту статью, прежде чем размещать вопрос, и сказал бы, что должен прочитать ее еще раз внимательно. - person Igor; 03.09.2010

Depesz недавно написал в блоге сообщение на странице "КАК УПРАВЛЯТЬ ИЗМЕНЕНИЯМИ В БАЗЕ ДАННЫХ?"

Я бы сказал:

  • Если вы просто сохраняете схему каждого объекта в SVN, вам по-прежнему необходимо развертывать изменения с упорядочением зависимостей и модификациями данных, поэтому все, что действительно покупает вас само по себе, - это категоризация вашей истории изменений по задействованным объектам.
  • Напишите сценарии для выполнения всех ваших изменений, включая сценарии для отмены ваших изменений.
  • Используйте apgdiff для создания различий схемы базы данных (PostgreSQL).
person Stephen Denne    schedule 02.09.2010

Вы можете использовать бесплатный другой инструмент PostgreSQL Diff Tool для баз данных PostgreSQL для сравнения вашей схемы разработки и производственной схемы. Вы просто обновляете свою базу данных для разработки так, как вам удобнее. Если вы хотите обновить производственную базу данных до состояния базы данных разработки, вы делаете дамп схемы (схем) базы данных разработки и схемы (схем) производственной базы данных и позволяете apgdiff сравнить их. Он выдаст вам результат, содержащий операторы DDL, необходимые для преобразования вашей производственной базы данных в состояние базы данных разработки.

Фактически, вам решать, как развернуть apgdiff в вашем цикле разработки, все, что он делает, это создает выходные данные с операторами DDL, чтобы «переместить» вашу производственную базу данных в то же состояние, что и база данных разработки.

На веб-сайте вы можете найти информацию о том, как это работает, как его использовать, какие операторы поддерживаются и т. Д. В моем блоге на www.fordfrog.name также есть статья об обновлении схемы PostgreSQL (мне разрешили включить только одну ссылку, поэтому не смог сделать и эту адресную ссылку).

person Miroslav Šulc    schedule 06.10.2010
comment
Спасибо, Миорослав, за ответ! Обязательно проверю свой блог. - person Igor; 07.10.2010