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

← →
Пит (2013-12-06 13:34) [0]

Кто-нибудь видел публичные программные решения типа СКВ, но под БД?

То есть, которые обеспечивают разработку под БД для группы разработчиков? Вроде:

- лок / анлок сущностей БД (таблиц, процедур, триггеров...) для их модификации (чтобы один разработчик не мешал другому, "взял" сущность на доработку - "вернул"
- ведение лога операций, чтобы изменения из тестовой БД перенести на боевую в автоматическом режиме

Ну и так далее.

← →
Ega23 © (2013-12-06 13:39) [1]

Скрипты отлично сидят в СКВ.

← →
Пит (2013-12-06 13:41) [2]

ну и в целом интересно кто как ведет разработку БД в группе разработчиков?

Допустим, примитивные варианты:

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

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

Кто какие варианты применяет, встречал?

← →
Sergey Masloff (2013-12-06 13:46) [3]

бгг
а главный ушел в отпуск ;-)

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

Нужна дополнительная системная табличка в которой хранить кто какой объект держит и триггером запрещать компиляцию объектов не-владельцам (с точки зрения системы контроля версий)

← →
Пит (2013-12-06 13:47) [4]

> Скрипты отлично сидят в СКВ.

Ох блин, ты и в прошлый раз не понял, что я имею в виду... Давай на примере:

1) в СКВ (которая как система связана с БД) залочил объект БД
2) далее меняешь объект через любимый клиент как угодно, сервер сохраняет лог DDL / DML операций.
3) разлочил объект БД в СКВ

Далее в СКВ видно, что некий Ega произвел такие то модификации с БД. Можно в автоматическом режиме накатить группу изменений на эталонную БД, фильтровать по измененным объектам, откатить, ставить релизные метки и прочее.

← →
Пит (2013-12-06 13:48) [5]

> бгг
> а главный ушел в отпуск ;-)

не понял

> Нужна дополнительная системная

Серег, я понимаю, да, система типа вашей.

Вопрос - встречал ли кто такие СКВ публичные?

← →
Пит (2013-12-06 13:49) [6]

> > бгг
> > а главный ушел в отпуск ;-)
>
> не понял

а, всё, понял))

Да понятное дело, в этом ручном режиме куча недостатков, не только главный в отпуск ушел. Но с этого начинают все, интересно кто до чего "дорос" в автоматизации этого процесса

← →
Ega23 © (2013-12-06 14:38) [7]

> Ох блин, ты и в прошлый раз не понял, что я имею в виду.
> .. Давай на примере:

Я всё прекрасно понял.
Это просто кое-кто в своей обычной манере выступил.
Извини, что ответил на вопрос, больше так не буду.

← →
Пит (2013-12-06 15:15) [8]

> Я всё прекрасно понял.

тогда я не понимаю, почему ты настойчиво говоришь про скрипты в файловой СКВ. Это ручная синхронизация, прочти еще раз что я имею в виду.

← →
Пит (2013-12-06 15:17) [9]

Sergey Masloff, может ты хоть знаешь открытые, публичные СКВ типа вашей? Ну или какой-то аналог?

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

← →
jumping jack (2013-12-06 16:43) [10]

Если "кто во что горазд", то логично в некоторые ключевые моменты (ключевые и для кода приложений, типа билдов) выгружать из базы метаданные в виде скрипта - их и сохранять в СКВ (всего 1 файлик)

полезным оказалось бы средство автоматической генерации апдейт-скрипта по двум таким "снимкам текущего состояния метаданных", но накрайняк хватит и возможности увидеть дифф между ними (между любыми двумя закоммиченными ревизиями/ветками БД)

← →
Ega23 © (2013-12-06 18:11) [11]

> Если "кто во что горазд", то логично в некоторые ключевые
> моменты (ключевые и для кода приложений, типа билдов) выгружать
> из базы метаданные в виде скрипта - их и сохранять в СКВ
> (всего 1 файлик)

Да можно всю метадату по базе выгружать в скрипт. Собственно, так и делается. И диффы можно между разными коммитами делать.
Вся проблема только в том, что ты также как и я ничего не понял. :)

← →
имя (2013-12-06 20:14) [12]

Удалено модератором

← →
имя (2013-12-06 20:41) [13]

Удалено модератором

← →
jumping jack (2013-12-06 21:40) [14]

Ega23 ©> ты также как и я ничего не понял. :)
да понял - хочется чуда чудесного, доселе невиданного, а мы с посконными деревяшками (ну - чем богаты...)

странно, что не озвучена СУБД - такие вещи наверняка привязаны к определенной
тормошите вендоров и прочих интеграторов

пишут, в Toad-е что-то такое вроде есть

← →
имя (2013-12-06 21:41) [15]

Удалено модератором

← →
jumping jack (2013-12-06 21:46) [16]

упоминают ищо какой-то "MS Visual Studio for Database Professionals"

ну и до кучи - может и не в тему - куча букв и ссылок: http://habrahabr.ru/post/121265/

← →
имя (2013-12-06 21:47) [17]

Удалено модератором

← →
имя (2013-12-06 21:49) [18]

Удалено модератором

← →
имя (2013-12-08 11:54) [19]

Удалено модератором

← →
Kerk © (2013-12-08 15:19) [20]

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

> - лок / анлок сущностей БД (таблиц, процедур, триггеров.
> ..) для их модификации (чтобы один разработчик не мешал
> другому, "взял" сущность на доработку - "вернул"

Такая штука имеет смысл только если все разработчики одновременно работают с одной схемой. Такое бывает, конечно, но редко. В остальных случаях вместо изобретения велосипедов куда удобнее пользоваться обычными системами контроля версий. В Toad есть интеграция с ними. В других нормальных IDE для работы с базами данных, скорее всего тоже это есть.

> - ведение лога операций, чтобы изменения из тестовой БД
> перенести на боевую в автоматическом режиме

Это деплоймент. Совершенно другая задача с контролем версий мало связанная. Для этого существует специальный софт, как правило стоящий денег. Тут много нюансов зависящих не только от названия СУБД, но и от ее версии.

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

Так что бери обычную систему контроля версий и покупай Toad. В нем есть и интеграция с контролем версий и функционал по сравнению и синхронизации схем :)

← →
Пит (2013-12-09 21:53) [21]

> акая штука имеет смысл только если все разработчики одновременно
> работают с одной схемой

конечно. Ну даже более того, с одной сущностью (таблицей там, хранимкой и пр)

> Такое бывает, конечно, но редко

у вас на каждого разработчика СВОЯ схема? А я наоборот - такого никогда не видел, ни разу в жизни, только когда разработчик один.

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

> Для этого существует специальный софт, как правило стоящий
> денег

ты, видимо, говоришь про деплоймент методом merge. Да, это нетривиальная задача, инструменты типа Power Designer и подобное.

← →
Kerk © (2013-12-09 22:21) [22]

> Пит (09.12.13 21:53) [21]
> у вас на каждого разработчика СВОЯ схема? А я наоборот -
> такого никогда не видел, ни разу в жизни, только когда
> разработчик один.

У каждого разработчика может быть даже несколько схем. Почему нет?

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

Можно провести аналогию с Delphi. Вот ты с коллегами синхронизируешь код с помощью системы контроля версий. Но при этом у вас ведь у каждого на диске есть своя копия кода, с которой вы и работаете.

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

Но тут уместная пословица про устав и монастырь. Кому как удобно.

← →
Пит (2013-12-09 22:34) [23]

Аргументация непонятна, поэтому я буду отвечать в твоем стиле, но в другую сторону )

> У каждого разработчика может быть даже несколько схем. Почему
> нет?

На весь проект может быть одна схема. Почему нет?

> А какой смысл всем работать с одной схемой?

а какой смысл каждому работать со своей схемой?

> Можно провести аналогию с Delphi. Вот ты с коллегами синхронизируешь
> код с помощью системы контроля версий. Но при этом у вас
> ведь у каждого на диске есть своя копия кода, с которой
> вы и работаете.

очень неуместная аналогия, по моему. На мой взгляд, некая сущность в БД (таблица, триггер, хранимка..) - это как файл в СКВ.
А схема - это как папка в проекте. Почему в проекте у каждого разработчика должна быть своя папка?

Над одним модулем (Core.pas) могут работать десятки людей, поэтому придумано СКВ, поэтому придуман merge. Точно также, как над одним Package в оракле могут работать также десятки людей.

> Кому как удобно.

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

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

Это все к тому, к твоей фразе:

> Такая штука имеет смысл только если все разработчики одновременно
> работают с одной схемой. Такое бывает, конечно, но редко

меня эта фраза дико удивила. Я то как раз считаю, что так происходит в 99% случаев, если это понимать как то, что несколько разработчиков могут копаться в одной схеме - вот именно так. Более того, в одном Package копаться - тоже только в путь. Да и с таблицами в общем тоже, просто вопрос не особо стоит, так как одновременное изменение одной таблицы двумя разработчиками маловероятно, хотя почему нет.

← →
Kerk © (2013-12-09 22:58) [24]

> Пит (09.12.13 22:34) [23]
> На мой взгляд, некая сущность в БД (таблица, триггер, хранимка.
> .) - это как файл в СКВ.
> А схема - это как папка в проекте. Почему в проекте у каждого
> разработчика должна быть своя папка?

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

Ты попробуй все-таки понять [22], там все предельно ясно.

> Но я как раз к тому, что ни разу в жизни не видел описанных
> тобой принципов работы, типа у каждого разработчика - своя
> схема. А если человек уволится?

Уволится - удалят его схемы, если они больше не нужны.

> Я то как раз считаю, что так происходит в 99% случаев, если
> это понимать как то, что несколько разработчиков могут копаться
> в одной схеме - вот именно так.

Да считай ради бога.

← →
Пит (2013-12-09 23:30) [25]

Короче, какой то пустой разговор.
Я рассказал про свой опыт. У тебя свой опыт - его я тоже понял.

Я говорю про автоматизацию своего способа, приблизительно описал как это вижу. Вот интересует - есть ли какие-то промышленные варианты, публичные программы.

← →
Kerk © (2013-12-09 23:54) [26]

Ну вот я тебе и сказал, что такие редкие частные случаи крайне нечасто коробочно автоматизируют. Если бы что-то такое существовало, тебе бы давно уже сообщили, да и сам бы нашел.

← →
Пит (2013-12-10 00:10) [27]

> Ну вот я тебе и сказал, что такие редкие частные случаи

ну вот тут мы и расходимся во мнениях. на мой взгляд, именно разделение схем по функционалу гораздо превалирует, чем разделение схем по разработчикам (ну допустим мы про оракл). Собственно, твоего варианта я не видел ни разу.

Собственно, я вообще не понимаю что автоматизировать в твоей схеме. Ты рассматриваешь вариант, когда разработчики НИКОГДА не работают над одной сущностью. Ясен фиг, что им СКВ просто не нужна. Ну максимум хранить историю изменений или типа того, Для этого можно и ручками сохранять в скрипт, который как файл в файловую СКВ, это да.

Именно в моем варианте речь идет о работе нескольких разработчиков над одной сущностью, и тут СКВ как раз как воздух нужна.

Собственно, точно также с файловыми СКВ. Знаю крупный проект, когда вообще все исходники хранили RAR"овскими архивами на файлохранилище. И ничего, работало. Строго до того времени, как не пришлось разным разработчикам одновременно работать над одним проектом и более того одним .pas модулем. Тогда да, черт ногу сломит и имеет смысл перенести разработку в СКВ. А если разработчики в своей деятельности не пересекаются - ну да, нафиг нужен контроль версий.

← →
jumping jack (2013-12-10 04:27) [28]

в терминологии промышленных средств разработки (типа MSVS и TOAD) всегда есть такая сущность, как ПРОЕКТ БД, состоящий из исходного кода, замечательно хранящегося в самых обычных СКВ и с их помощью синхронизирующаяся/ветвящаяся/мержащаяся (т.е. обычная СКВ даёт возможность совместной работать над ПРОЕКТОМ БД нескольким разработчикам одновременно, полностью аналогично программным проектам)
и есть процесс синхронизации этого ПРОЕКТА с реальной БД в ту или иную сторону
(конечно, преобразование данных в эту простую схему не совсем хорошо вписывается, но в основе "стандартного подхода" лежит все-таки она)
как-то так, ИМХО

← →
ухты (2013-12-10 11:42) [29]

Удалено модератором

← →
ухты (2013-12-10 11:43) [30]

Удалено модератором

> Пит (10.12.13 00:10) [27]
> Ты рассматриваешь вариант, когда разработчики НИКОГДА не
> работают над одной сущностью. Ясен фиг, что им СКВ просто
> не нужна.

Боже мой, как все печально-то.
Что мешает работать над одной и той же сущностью, но в разных схемах, синхронизируясь через контроль версий? Ты придумал тут реально какую-то невообразимую фигню. Представить страшно, в каких шарашках ты всего этого насмотрелся.

> jumping jack (10.12.13 04:27) [28]
>
> в терминологии промышленных средств разработки (типа MSVS
> и TOAD) всегда есть такая сущность, как ПРОЕКТ БД, состоящий
> из исходного кода, замечательно хранящегося в самых обычных
> СКВ и с их помощью синхронизирующаяся/ветвящаяся/мержащаяся
> (т.е. обычная СКВ даёт возможность совместной работать над
> ПРОЕКТОМ БД нескольким разработчикам одновременно, полностью
> аналогично программным проектам)

Вот! Вот совершенно нормальная практика. И нет в ней никакой привязки к одной на всех схеме :)

Про ветвление ты здорово вспомнил. Если всех загнать в одну схему, то такая простая вещь как ветвление становится недоступной.

← →
Sergey Masloff (2013-12-10 15:26) [33]

Я все же чего-то не понимаю...

В случае с программным кодом компилятор (обычно) все же на машине разработчика.

В предлагаемой схеме я просто не понимаю как это работает. Есть продакшн база. В ней есть код (допустим триггера - неважно) я хочу его взять и править

1) Какие боком мне тут поможет СКВ (обычная).
2) Как может (даже теоретически) выглядеть ветвление

← →
Sergey Masloff (2013-12-10 15:30) [34]

Ну и еще я посмотрю что она мне смержит если я на какой-нибудь таблице констрейнтов добавлю или полей удалю ;-)

← →
Пит (2013-12-10 15:30) [35]

> в терминологии промышленных средств разработки (типа MSVS
> и TOAD) всегда есть такая сущность, как ПРОЕКТ БД, состоящий
> из исходного кода, замечательно хранящегося в самых обычных
> СКВ и с их помощью синхронизирующаяся/ветвящаяся/мержащаяся

я сути работы не понял.

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

Можно описать последовательность их действий с учетом СКВ?

← →
Пит (2013-12-10 15:32) [36]

Sergey Masloff, слушай, ну ты хоть знаешь публичные системы, аналогичные Сам_знаешь_какой? )
А то тут эксперты говорят, что такой бред только в шарашкиных конторах возможен

← →
Пит (2013-12-10 15:39) [37]

и кстати, Kerk, если я все таки что-то понял, то как раз в твоей идеологии у базы данных может быть только ОДНА схема. Размноженная на N-разработчиков.

А что делать, если в эталонной БД есть несколько схем? (например, S_CORE, S_BRANCH, ...) они должны быть размножены также на всех разработчиков?

S_CORE_KERK
S_BRANCH_KERK
S_CORE_ANDREY
S_BRANCH_ANDREY
...

Так что ли вы работаете?

> Sergey Masloff (10.12.13 15:26) [33]
>
> В предлагаемой схеме я просто не понимаю как это работает.
> Есть продакшн база. В ней есть код (допустим триггера -
> неважно) я хочу его взять и править
>
> 1) Какие боком мне тут поможет СКВ (обычная).
> 2) Как может (даже теоретически) выглядеть ветвление

1) Ничем не поможет. Не надо делать ручных изменений в продашн базе.
2) Делаешь в СКВ бранч последней версии кода, заливаешь все эти объекты в отдельную схему. Работаешь в этой схеме, никому не мешая. Изменения сохраняешь в свой бранч в СКВ. Когда все готово, мержишь его с основной веткой. Когда приходит время, основную ветку деплоят в продакшн базу.

Ну куда уж проще-то, а? :)
Сергей, я видел как у вас все устроено. Благодаря тем штука, которые вы сами для себя сделали, все это весьма грамотно работает. Но у вас реально уникальная ситуация. Во многих других случаях работа всех в одной схеме вызвана исключительно разгильдяйством. Если такой софт как у вас был много у кого, Пит давно бы его нашел :)

> Пит (10.12.13 15:39) [37]
>
> и кстати, Kerk, если я все таки что-то понял, то как раз
> в твоей идеологии у базы данных может быть только ОДНА схема.
> Размноженная на N-разработчиков.

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

> А что делать, если в эталонной БД есть несколько схем? (например,
> S_CORE, S_BRANCH, ...) они должны быть размножены также
> на всех разработчиков?
>
> S_CORE_KERK
> S_BRANCH_KERK
> S_CORE_ANDREY
> S_BRANCH_ANDREY
> ...
>
> Так что ли вы работаете?

Типа того. Конкретные имена - это уже дело вкуса.

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

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

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

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

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

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

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