Комментарии 27
Doctrine\DBAL\Schema\Comparator
А не проще хранить каноническую схему базы данных в репозитарии вместе с кодом, а при выкатке новой версии запускать синхронизатор схемы, который вычислит разницу между канонической схемой и реальной, и выдаст (или автоматически выполнит) нужные SQL-операторы, чтобы привести базу к нужному состоянию?
В описанном Вами случае правильнее использовать миграцию баз данных, которая описывает состояние баз данных на определенный момент времени и позволяет откатить базу данных на определенную точку.
Данный скрипт не про это: он для наглядного представления разницы в двух базах, а не для приведения двух баз к одному состоянию.
Данный скрипт не про это: он для наглядного представления разницы в двух базах, а не для приведения двух баз к одному состоянию.
Да это понятно. Просто обе проблемы, которые вы описали, можно решить полностью автоматически, без человеческого фактора, без риска чего-нибудь упустить.
речь идет о том, что подобная ситуация не должна вообще происходить, потому что в приличных местах используют миграции, живущие вместе с кодом. Хотя, конечно, понятно, что она в реальной жизни будет происходить регулярно, как только появится выделеннный DBA.
Поделитесь, как организуется миграция?
У меня работает несколько команд разработчиков над разными модулями, и я спрашивал у разных разработчиков, как организовать сверку схем, но никто не предложил что-то полностью автоматическое. В результате сделали в репозитории папки со скриптами, которые содержат изменения в схеме.
У меня работает несколько команд разработчиков над разными модулями, и я спрашивал у разных разработчиков, как организовать сверку схем, но никто не предложил что-то полностью автоматическое. В результате сделали в репозитории папки со скриптами, которые содержат изменения в схеме.
Посмотрите
https://github.com/dlevsha/nasgrate
на мой взгляд, данный вопрос более менее раскрыт в описании
https://github.com/dlevsha/nasgrate
на мой взгляд, данный вопрос более менее раскрыт в описании
В SQLYog можно сравнить структуры
А сложно доделать сравнение имеющейся базы с .sql файлом, создающим её? Но без выполнения этого .sql файла. А то часто инсталлер расходится с имеющейся базой, а по патчам довольно муторно восстанавливать структуру.
Дополнительно, бывает полезно сравнить индексы, триггеры. Для MS SQL часто «разъезжаются» job's
Обычно это Navicat-ом делаю.
1) Вам стоит пересмотреть шрифты. Это же не нью йорк таймс. Используйте что-то более современное без засечек, а для листинга полей программерский моноширный шрифт вроде courier new.
2) Строки коннектов нужно дать возможность ввести на лету в форму или просто input:text. Не всегда работа идет с одним и тем же проектом, иногда нужно просто сравнить что-то мелкое и забыть. Без создания конфигов и пр.
Спасибо, попробую воспользоваться в будущем.
1) Вам стоит пересмотреть шрифты. Это же не нью йорк таймс. Используйте что-то более современное без засечек, а для листинга полей программерский моноширный шрифт вроде courier new.
2) Строки коннектов нужно дать возможность ввести на лету в форму или просто input:text. Не всегда работа идет с одним и тем же проектом, иногда нужно просто сравнить что-то мелкое и забыть. Без создания конфигов и пр.
Спасибо, попробую воспользоваться в будущем.
При всем уважении, это похоже на инструмент для решения симптомов, но не проблемы (расхождение схемы данных).
Но даже без учета этого не легче ли было сделать консольное приложение? которое, кстати, может спрашивать реквизиты подключения к БД без необходимости хардкода их для скрипта.
Но даже без учета этого не легче ли было сделать консольное приложение? которое, кстати, может спрашивать реквизиты подключения к БД без необходимости хардкода их для скрипта.
sqlyog уже не раз юзал для этих целей. navicat по-моему тоже умеет. скармливаешь системе 2 конекшена и все. ну и она не только показывает дифы, а ещё и может применить их
Пользовались для этого Toad.
Текст хранимых процедур анализируете?
Текст хранимых процедур анализируете?
Еще тогда вам feature request: сравнение ENGINE, CHARSET, COLLATE.
А в целом действительно полезная утилитка (особенно для консоли).
А в целом действительно полезная утилитка (особенно для консоли).
Сравнивать схемы (помимо прочего) можно еще в DBeaver — бесплатное, опен-сорсное, мультиплатформенное и мультибазное.
Фича правда пока сыровата, в частности не умеет генерить diff-DDL. Но если будут реквесты — доделается.
Фича правда пока сыровата, в частности не умеет генерить diff-DDL. Но если будут реквесты — доделается.
Я бы сказал — в некоторых случаях.
Разных административных операций над базой существуют тысячи, часто они пересекаются по функционалу. Ставить тысячи маленьких утилит, каждую со своими граблями и косяками — тоже не всегда удобно.
Про конкретно обсуждаемый случай — по мне сравнение схем БД в гуе куда удобней чем в консоли. Равно как и мёрж текстовых дифов. Только для БД еще нужна уйма конфигурации.
Разных административных операций над базой существуют тысячи, часто они пересекаются по функционалу. Ставить тысячи маленьких утилит, каждую со своими граблями и косяками — тоже не всегда удобно.
Про конкретно обсуждаемый случай — по мне сравнение схем БД в гуе куда удобней чем в консоли. Равно как и мёрж текстовых дифов. Только для БД еще нужна уйма конфигурации.
Используем Doctrine Mogrations для работы уже давно
Случая с расхождением баз в деве и на продакшене ни разу не встречали
Ну только если забыли выполнить миграцию при выводе на продакшен.
Но это решилось автоматическим деплоиментом через Capistrano.
Причина вашей ситуации скорее системная и решать ее надо системно, а не писать инструменты для исправления.
Случая с расхождением баз в деве и на продакшене ни разу не встречали
Ну только если забыли выполнить миграцию при выводе на продакшен.
Но это решилось автоматическим деплоиментом через Capistrano.
Причина вашей ситуации скорее системная и решать ее надо системно, а не писать инструменты для исправления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Compalex: сравнение схем двух баз данных