| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Синхронизация разработки СУБД? |
| Автор: GSMD 1.11.2006, 17:07 |
| Проблема не нова, может, кто подскажет толковую идею? Ведется разработка клиент-серверного приложения, работа з базой - через JDBC, сама база - PostgreSQL. На сервере находится одна копия без пользовательских данных и одна - с тестовыми данными. В начале рабочего дня (условно) каждый разработчик делает копию базы и работает с ней на localhost, после чего, при благоприятном стечении обстоятельств, вносит те же изменения в обе базы на сервере, делает дамп той базы, что без данных, кладет его в SVN и работа считается завершенной. Вся эта инфраструкрура выглядит несколько корявой, т.к. есть вероятность что разработчик забудет перенести изменения с локалхоста на базу на сервере, или перенесет неполностью. Есть ли какие-либо инструменты для автоматического приведения структуры одной БД к структуре другой? У кого какой workflow в данном вопросе? |
| Автор: chief39 1.11.2006, 19:35 |
| Ранее участвовал в проекте... Делали так: Есть изначальный дамп БД. Старый. Но с реального боевого сервера Есть много скриптов(DDL, процедуры, вставки/апдейты ) залив дамп и запустив все скрипты - получаем последнюю версию. Ну а уже скрипты - под ЦВСом  ЗЫ: для запуска всех свкиптов и проверки их на скриптовость писали маленькую свою утилку |
| Автор: GSMD 6.11.2006, 17:42 |
| chief39, вариант. |
| Автор: chief39 7.11.2006, 14:44 |
| Кроме того - неплохо бы скрипты по откату таблиц тоже писать. На случай, если на боевых серверах не проканает "накат" версии |
| Автор: GSMD 7.11.2006, 16:12 |
| chief39, м-м-м, обсужу с разработчиками (я - project manager ;)). Хотя типичность задачи заставляет предполагать возможность наличия стандартных утилит. Не нашел. |
| Автор: LSD 7.11.2006, 22:59 |
| Уже http://forum.vingrad.ru/topic-83974.html и похоже решения, все же толкового решения нет. Проблема в том, что база содержит в себе данные которые надо апгрейдить/доунгрейдить. Код данных не содержить, максимум это ресурсы, но они таскаются как есть с каждой версией. |
| Автор: chief39 8.11.2006, 12:06 | ||
Да. Кроме описанного мной, предпринимались ещё всякие мелкие ухищрения и контроли... "До кучи" писалась утилитка для управления скриптами и даже немного версионности помимо ЦВСа... Но всё равно следить за этим приходилось одному человеку. Некоторое время - мне. |
| Автор: GSMD 8.11.2006, 12:23 |
| Наткнулся на http://www.sqlmanager.net/ - буду пробовать. Может, чем поможет. |
| Автор: chief39 13.11.2006, 15:32 | ||
Ну как? Если сервак MS и есть утилка заточеная под него - я думаю, должна была подойти |
| Автор: GSMD 14.11.2006, 10:27 |
| chief39, сервак не MS, а PostgreSQL. C софтиной начал разбираться только сейчас. В составе всего того комплекта под названием EMS SQL Manager есть компоненты DB Comparer 2006(an excellent tool for database comparison and synchronization) и Data Comparer 2005a powerful and easy-to-use utility for data comparison and synchronization. Стоят одинаково (USD95). Первая позволяет сравнивать базы, вторая - только таблицы. Зачем нужна вторая при наличии первой сказать сходу не могу. Но похоже - оно. |
| Автор: batigoal 14.11.2006, 23:03 | ||
У меня есть подозрение, что первая сравнивает структуру базы, вторая - содержимое таблиц. По крайней мере, Oracle Change Manager при сравнении данные в схемах не анализирует. |
| Автор: chief39 15.11.2006, 14:03 |
| Кстати... уточните, плиз, что именно версионным должно быть - только структура и процедуры/триггера или данные тоже? Потому как я сотоварищи использовал описанный мною путь для неких базовых данных в том числе. |
| Автор: Romkin 15.11.2006, 14:44 | ||
Я тоже ищу Увы, иногда и некоторые данные перерабатывать приходится. В принципе, все решается скриптом, но вопрос как раз в том, что нужно не просто менять текст процедуры, например, но и выполнять код преобразования данных. Редко, но нужно. Сейчас решается полуручным способом: если кому-то надо сделать изменения в БД, он идет в общий каталог и создает там текстовый файл с очередным номером, в нем и пишет все изменения, которые надо сделать, после - проверка, что все написано правильно. При поставке смотрится номер имеющегося обновления, и все обновления с номерами болше - загружаются в БД. БД контролирует при этом, чтобы не было пропусков. Лучшего, увы, не придумали  |
| Автор: GSMD 15.11.2006, 19:10 |
| batigoal, ага, так оно и есть. chief39, необходимы оба варианта, т.к. с одной стороны, есть "чистая база", поставляемая новым клиентам, с другой - существующие инсталляции, которые необходимо обновлять до текущей версии базы. Сорри, если в каких-то моментах очевидно неправ: я в первую очередь project manager, в программировании пока не очень силен ;) В принципе, мне продукт от EMS понравился, еще у них есть удобная (наверное) штука, позволяющая набивать таблицы базы тестовыми данными. Romkin, а каким образом БД контролирует? В принципе, неплохой вариант. И может пригодиться, учитывая что... Задача в принципе не совсем тривиальная, т.к. разрабатываемый продукт клиент-серверный (естественно), но предназначен для большого количества мелких заказчиков (что делает его поддержку затратной), и я подумываю о системе автоматического обновления (через инет, или же клиент устанавливает dial-up соединение с нашим сервером - не принципиально). Ладно - обновить .jar - это не проблема, а вот с базой - это уже сложнее. Вероятно, будет что-то в стиле метода г-на Romkin, если он еще поделится каким образом база конролирует непропуск патчей. Т.е. при удаленном обновлении загружаются все патчи базы, непосредственно перед применением их делается backup базы (вероятно, ночью). И, собственно, выполняются эти скрипты-патчи. Как вам, уважаемые, такая концепция? |
| Автор: Romkin 15.11.2006, 19:58 |
| Ну контроль наполовину организационный: Если одному из разработчиков нужна процедура в бд, он идет в расшаренный каталог и организует там текстовый файл, с очередным номером. Синхронизации не надо, нужно сравнительно редко, и коллизий не бывает. Первой же строчкой в этом скрипте он должен записать вызов процедуры и подать ей на вход номер скрипта (второй - для чего он нужен ;) ). НУ а дальше - элементарно, процедура пишет этот номер и время в таблицу, попутно контролируя, есть ли предыдущий. Если нет - исключение. Вполне достаточно. Плюс - у приложения в свойствах номер внутреннего билда всегда соответствует номеру изменения. Ну и есть приложение, которое объединяет эти файлы в один, но обычно и не используется: мы обновляем при выезде. Перед выездом все проверяется, на наличие вызова и тд. |
| Автор: chief39 17.11.2006, 12:44 |
| Вопчем было у меня так: скрипты - текстовые файлы. Нужно добавить/изменить поле, таблицу, индех, процедуру etc - пишется скрипт. Если понимаешь что надо поле уничтожить и создать его с другим типом - пишется скрипт с таким же именем но следующим порядковым номером. В каждом экземпляре БД есть табличка, куда заносится имя каждого скрипта при выполнении и версия. Порверяет, заносит в таблицу и запускает скрипты спец утилитка - её надо писать ручками(но эт недолго) Если скрипт xxx.sql уже есть, а надо добавить ещё поле - пишется xxx.2.sql Надо добавить ещё одно поле - пишется xxx.3.sql Надо убрать первое и пересоздать второе с копией данных - пишется xxx.4.sql Если на конкретной БД был уже запущен xxx.2.sql - то утилка запускает 3 и 4. Строго по порядку А разработчик скрипта имеет исходные данные - структура, нужная после выполнения его скрипта + структура БД после выполнения предыдущей версии скрипта. Он должен написать его так, чтоб БД корректно перевелась из состояния 2 в состояние 3. А утилка гарнтирует что запустятся все скрипты: xxx.sql xxx.2.sql xxx.3.sql xxx.4.sql И строго в таком порядке Процедуры проще - пишешь новую версию процедуры и увеличиваешь номер - коректно переводить ничего не надо - процедура/триггер просто заменит имеющуюся. |
