Форум: "Прочее";
Текущий архив: 2014.07.06;
Скачать: [xml.tar.bz2];
Внизсистема контроля версий для БД Найти похожие ветки
← →
Пит (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]Удалено модератором
← →
Kerk © (2013-12-10 13:56) [31]
> Пит (10.12.13 00:10) [27]
> Ты рассматриваешь вариант, когда разработчики НИКОГДА не
> работают над одной сущностью. Ясен фиг, что им СКВ просто
> не нужна.
Боже мой, как все печально-то.
Что мешает работать над одной и той же сущностью, но в разных схемах, синхронизируясь через контроль версий? Ты придумал тут реально какую-то невообразимую фигню. Представить страшно, в каких шарашках ты всего этого насмотрелся.
← →
Kerk © (2013-12-10 14:02) [32]
> 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
...
Так что ли вы работаете?
← →
Kerk © (2013-12-10 15:48) [38]
> Sergey Masloff (10.12.13 15:26) [33]
>
> В предлагаемой схеме я просто не понимаю как это работает.
> Есть продакшн база. В ней есть код (допустим триггера -
> неважно) я хочу его взять и править
>
> 1) Какие боком мне тут поможет СКВ (обычная).
> 2) Как может (даже теоретически) выглядеть ветвление
1) Ничем не поможет. Не надо делать ручных изменений в продашн базе.
2) Делаешь в СКВ бранч последней версии кода, заливаешь все эти объекты в отдельную схему. Работаешь в этой схеме, никому не мешая. Изменения сохраняешь в свой бранч в СКВ. Когда все готово, мержишь его с основной веткой. Когда приходит время, основную ветку деплоят в продакшн базу.
Ну куда уж проще-то, а? :)
Сергей, я видел как у вас все устроено. Благодаря тем штука, которые вы сами для себя сделали, все это весьма грамотно работает. Но у вас реально уникальная ситуация. Во многих других случаях работа всех в одной схеме вызвана исключительно разгильдяйством. Если такой софт как у вас был много у кого, Пит давно бы его нашел :)
← →
Kerk © (2013-12-10 16:00) [39]
> Пит (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"овского подхода, поэтому и удивился, что это уникально.
Хотя, если бы была статистика кто как работает - было бы любопытно.
← →
Пит (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]Тут хитрость имеется... Есть купленная утилитка, которая сравнивает БД и генерирует собсна скрипт.
← →
Kerk © (2013-12-10 20:53) [56]
> Пит (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]Удалено модератором
Примечание: Создание пустых сообщений
← →
Cobalt © (2013-12-15 14:46) [59]Попробуй обратиться в Эмбаркадеро - у них какие-то инструменты для БД есть.
ER Studio и всё такое.
Даже вебинары где-то выкладывались.
Хотя, быстрее будет им позвонить в российское представительство - они наверняка все материалы вышлют, а то еще и пригласят показать.
← →
Пит (2013-12-19 16:42) [60]парам пам пам
← →
asail © (2013-12-19 17:07) [61]турум турум
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2014.07.06;
Скачать: [xml.tar.bz2];
Память: 0.66 MB
Время: 0.005 c