система контроля версий для БД

← →
Пит (2013-12-10 16:17) [40]

ну наконец, после маленького срача, мне кажется, мы поняли друг друга. Я понял как работает у Kerk, и Kerk понял, что я имел в виду.

Единственное, с чем несогласен:

>Но у вас реально уникальная ситуация

не понимаю, что тут уникального. Маслов так работает (какое счастье, а то Kerk бы так и продолжал утверждать, что это все дело шарашкиных контор), все места, где я видел работу - организованы также. И ни разу не видел Kerk"овского подхода, поэтому и удивился, что это уникально.
Хотя, если бы была статистика кто как работает - было бы любопытно.

← →
Пит (2013-12-10 16:19) [41]

> А если я вдруг скажу, что инстансов Oracle тоже можно быть
> больше одного (а почему нет?)

а что такого - тоже видел. Никто ведь дблинки на крайний случай не отменял.

> Это не в моей идеологии, это в идеологии Oracle схема равна
> юзеру

это так тянулось исторически и я как раз думал, что такой подход давным давно устарел.
К тому же, сейчас, насколько я помню, немного не так. Да, у каждого юзера (учетки) есть схема, но не у каждой схемы есть юзер.

← →
Kerk © (2013-12-10 16:20) [42]

> Пит (10.12.13 16:17) [40]
> все места, где я видел работу - организованы также

Ну это бывает, что так совпало.

> Хотя, если бы была статистика кто как работает - было бы
> любопытно.

Статистики у меня нет, но то, что Toad и другие популярные IDE имеют инструменты для поддержки "моего" подхода и ничего не знают про "твой" подход, позволяет сделать некоторые выводы :)

← →
Kerk © (2013-12-10 16:34) [43]

> какое счастье, а то Kerk бы так и продолжал утверждать,
> что это все дело шарашкиных контор

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

← →
Пит (2013-12-10 16:39) [44]

> Toad и другие популярные IDE имеют инструменты для поддержки
> "моего" подхода

лично ты пользуешься в Toad"е таким подходом?

Вообще, все таки было бы интересно рассмотреть от начала до конца. Вот есть некая сущность в продакшне - пусть будет схема MAIN_CORE, пакет COMMON_PROC.

Два разработчика решили изменить пакет COMMON_PROC, один изменить текущую процедуру, другой добавить новую процедуру.

Можно описать всю цепочку, начиная от конкретного разработчика, до вывода нового функционала на продакшн?

← →
Пит (2013-12-10 16:40) [45]

> Ситуация Маслова уникальна тем, что они сделали себе тулзы.
> А что происходит там, где работают так же, но без этих
> тулз..

Kerk, а ты как думаешь - сначала написали эти тулзы, а потом стали так работать, или было наоборот?

← →
Kerk © (2013-12-10 16:48) [46]

> Пит (10.12.13 16:39) [44]
>
> > Toad и другие популярные IDE имеют инструменты для поддержки
> > "моего" подхода
>
> лично ты пользуешься в Toad"е таким подходом?

Конечно. Я о чем тут пишу-то с самого начала? :)
Причем Toad тут всего-лишь промежуточное звено, СКВ можно использовать и без него. Порою это даже удобнее.

> Вообще, все таки было бы интересно рассмотреть от начала
> до конца. Вот есть некая сущность в продакшне - пусть будет
> схема MAIN_CORE, пакет COMMON_PROC.
>
> Два разработчика решили изменить пакет COMMON_PROC, один
> изменить текущую процедуру, другой добавить новую процедуру.

Слушай, ну вот реально, можно я поленюсь и пошлю тебя перечитать [22] ?

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

Ну вот вообще никакой разницы с описанной ситуацией нет.

> Kerk, а ты как думаешь - сначала написали эти тулзы, а потом
> стали так работать, или было наоборот?

Это пусть Сергей расскажет, если желание будет :)

← →
jumping jack (2013-12-10 16:59) [47]

Пит> Два разработчика решили изменить пакет COMMON_PROC, один изменить текущую процедуру, другой добавить новую процедуру.

так полностью же аналогично работе с кодом, только компиляция/сборка заменена автоматизированным апдейтом базы по её проекту (вот на этом этапе возможны тонкости, но не на этапе работы с кодом)
1) код пакета уже есть в СКВ, оба разработчика создают свои ветки проекта из транка, загружают код себе, работают с ним, проверяют, если надо, на своих рабочих копиях базы, коммитят обратно в СКВ
2) оба по очереди либо ответственный за проект вливает ветки в транк СКВ (решая конфликты объединения, если вдруг возникнут) если "один изменил текущую процедуру, другой добавил новую" - конфликтов не будет, всё сольётся автоматом
3) запускается автоматический процесс апдейта базы по проекту в СКВ (но если при этом требуется преобразование хранящихся в базе данных - детали этого процесса я прояснить не смогу)

← →
Пит (2013-12-10 17:05) [48]

> Ну вот вообще никакой разницы с описанной ситуацией нет.

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

Ладно, ок:

- имеется две одинаковые по содержимому схемы (синхронизированы типа): MAIN_CORE_N1, MAIN_CORE_N2
где N1 и N2 - разрабы

- первый разработчик через любимого клиента модифицирует пакет COMMON_PROC в схеме MAIN_CORE_N1, второй разраб соответственно тот же пакет в MAIN_CORE_N2

- Далее они ручками из клиента экспортируют схему в SQL-файл? Первый экспортирует MAIN_CORE_N1, второй экспортирует MAIN_CORE_N2 и как файл пытаются записать в файловую СКВ.
Соответственно, при возникновении конфликта - ручной MERGE.

- В случае осуществленного MERGE - обратно из скрипта перезаливают схему свою?

Все так или как то иначе?

Куча вопросов:

1) получается, приходится мерджить всю схему целиком, а ведь она может быть огромной, с сотней пакетов?

2) нет ли такого конфликта, что при экспорте схем там где-то будет присутствовать название схемы? Которое разное у разных разработчиков.

3) означает ли это, что SQL-клиенты (toad, pl/sql dev) должны быть одинаковыми у всех разрабов, ибо разные клиенты могут по разному экспортировать схему?
Причем, возможно, одинаковой версии.

4) Что делать с данными?
При работе в общей схеме человек делает DDL, а потом, допустим, заливает в справочники первоначальные, необходимые для работы данные. Как эти данные попадают в "альтернативные" схемы других разработчиков?

Также непонятен вопрос с данными как таковыми. Если скрипты в СКВ содержатся именно в идеологии, что один скрипт создает одну схему с нуля, то тогда при обновлении каждый раз будут дропаться все объекты схемы и создаваться заново, восстанавливая эталонный вид из СКВ, как с этим бороться?

Если же в СКВ хранятся инкрементные обновления, то тогда непонятно как они вообще формируются.

← →
Kerk © (2013-12-10 17:30) [49]

Ты опять вернулся к режиму восприятия "схема базы данных", которую ты и экспортируешь зачем-то одним куском. А на самом деле одна сущность БД = одному файлу в СКВ. Эти файлы можно редактировать по отдельности. Если нужно модифицировать данные, то пишется скрипт и тоже кладется в SQL-файлы. А название схемы лучше нигде в коде не упоминать, незачем это.

← →
Пит (2013-12-10 17:59) [50]

> Ты опять вернулся к режиму восприятия "схема базы данных"

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

← →
Kerk © (2013-12-10 18:08) [51]

Берешь файл пакета из СКВ, выполняешь на своей схеме, чтоб убедиться, что у тебя он самый свежий. Работаешь с ним. Когда закончил, сохраняешь код пакета в файл и кладешь обратно в СКВ. Вот и все. Я реально искренне не понимаю, что тут может быть непонятно. Точно такая же куча файлов с кодом, как когда ты с Delphi работаешь. Точно так же синхронизируешь эту кучу с остальными через СКВ.

← →
Пит (2013-12-10 18:19) [52]

> Когда закончил, сохраняешь код пакета в файл и кладешь обратно
> в СКВ

как быть с constraint? С job"ами?

И я не понял насчет предопределенных данных в таблицах, например. Как с ними поступают?

В каком виде пишется метаинформация о таблице? Как CREATE OR REPLACE TABLE? Но тогда любая синхронизация таблицы уничтожит текущую вместе с данными, которые, возможно, уже накоплены для теста. С этим как?

← →
asail © (2013-12-10 19:10) [53]

Расскажу про наш лисапед...
Базы Interbase, несколько отличающиеся друг от друга для разных клиентов/версий.
В VSS сидит эталонная база целиком (прям файл GDB и сидит). Тот, кто хочет править структуру, делает чек-аут и делает свои изменения. После чего - чек-ин.
Часть таблиц содержат предопределенные данные, ессно их тоже мона править и загружать в эталон.
При чек-ине в комменты заносится список изменений.
Далее, что касается деплоймента:
1. С помощью собственной утилитки берется последняя версия с VSS и генерируется некий апдейт-пакадж (зип), который включает полные метаданные эталонной БД, файлы с данными таблиц имеющих предопределенные данные и дополнительные файлы со скриптами типа update/insert/delete, если нужно (тоже сидят в VSS).
2. Полученный пакадж запускается у клиента на целевой базе с помощью другой нашей утилиты, которая:
а) вытягивает метаданные с целевой базы, сравнивает их с эталонной и генерирует скрипт на изменения.
б) потом заливает предопределенные данные и запускает дополнительные скрипты изменения данных.

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

← →
Пит (2013-12-10 19:30) [54]

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

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

← →
asail © (2013-12-10 19:41) [55]

Тут хитрость имеется... Есть купленная утилитка, которая сравнивает БД и генерирует собсна скрипт.

> Пит (10.12.13 18:19) [52]
>
> > Когда закончил, сохраняешь код пакета в файл и кладешь обратно
> > в СКВ
>
> как быть с constraint? С job"ами?
>
> И я не понял насчет предопределенных данных в таблицах,
> например. Как с ними поступают?

А их-то какая проблема текстом хранить? Кладешь скрипты создания так же в СКВ. Данные из справочников отлично хранятся в виде пачки INSERT-ов.

> В каком виде пишется метаинформация о таблице? Как CREATE
> OR REPLACE TABLE? Но тогда любая синхронизация таблицы уничтожит
> текущую вместе с данными, которые, возможно, уже накоплены
> для теста. С этим как?

It depends, как говорится. Могут хранить первоначальный CREATE TABLE и пачку ALTER-ов. Всякое бывает, но опять же все - текст.

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

В итоге, как мне кажется, СКВ идеально предназначены для хранения текстов. Почему бы не хранить в них тексты? :)

← →
jumping jack (2013-12-10 21:08) [57]

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

но, к счастью, очень часто и у многих возникающая, поэтому готовые решения есть (например, как утверждают, в TOAD, да и в других более-менее продвинутых средствах)

← →
Пит (2013-12-12 15:00) [58]

Удалено модератором
Примечание: Создание пустых сообщений

Попробуй обратиться в Эмбаркадеро - у них какие-то инструменты для БД есть.
ER Studio и всё такое.
Даже вебинары где-то выкладывались.
Хотя, быстрее будет им позвонить в российское представительство - они наверняка все материалы вышлют, а то еще и пригласят показать.

← →
Пит (2013-12-19 16:42) [60]

парам пам пам

турум турум

система контроля версий для БД Найти похожие ветки