Проектирование БД

← →
bss (2010-10-22 18:14) [40]

> откуда разворачивать базу?
>
> Из эталонного образа

абсолютно ненужный ответ. Хорошо, каким образом составляется эталонный образ?

> Проектирует на бумажке и вживую, в кейс (если считает нужным)
> вносит общие (на макроуровне) схемы

То есть, в кейсе у вас нету непосредственно структуры таблиц? Нет непосредственных связей одной таблицы с другой?

> >Каким образом составляется кейс, который может развернуть
> всю БД?
> >Или каким образом составляется скрипт, который разворачивает
> БД?
> Никаким. Не разворачиваем базу из кейса

ну так я два варианта предложил. Или из кейса разворачивать, или из некоего скрипта. Как еще?
В кейсе вы не ведете - я понял.

Тогда каким образом составляется общий скрипт развертывания базы?

> Есть перехватчик который журналирует весь DDL (на самом
> деле у нас и весь DML) этот DML потом проигрывается на target
> системах (не весь естественно а в соответствии с правилами).
>

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

В твоем случае проще сравнить девелоперскую БД с БД предыдущей версии и получить скрипты непосредственно перехода. Перехватывая DDL вы еще и таким образом формируете историю изменения метаданных. Простой пример, завели табличку, потом поняли что не нужна - дропнули. При сравнении эталона с девелоперской ничего и не будет, в вашем подходе вы перехватите CREATE TABLE, а потом ее DROP.

И все таки как вы отличаете мусорные данные (не требующие переноса на эталон) от необходимых для перехода данных? Очень интересует про эти "в соответствии с правилами".
Опять же, если есть правила - проще сравнить две БД и увидеть именно актуальные изменения. А если вы перехватываете все DDL...

> Смысла в заливке из скрипта не вижу, делаем через экспорт-
> импорт

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

← →
bss (2010-10-22 18:20) [41]

> Хотите сказать то, что Вы делаете и то, что получается -
> в принципе не одно и то же?

не понял вопроса

> друпал твоё всё, там это уже давно решено: и установка,
> и модификация, и выполнение "долгих" "удалённых" инсталляций.
> .

это какой-то модуль к какой-то CMS системе как я понял. Как это связано с задачей?

Или там реализованы какие-то принципы? Можно рассказать тогда об этим принципах?

← →
Anatoly Podgoretsky © (2010-10-22 18:41) [42]

> Inovet (22.10.2010 18:03:39) [39]

Ну значит это 486 был, столько лет прошло, мог забыть. А вот такую
гигантскую стену не забыть. Около стены стояли стремянки, вроде на колесах.

← →
Sergey Masloff (2010-10-22 18:44) [43]

bss (22.10.10 18:14) [40]
Извини, мне кажется ты нарисовал какую-то свою картину и просто пытаешься читать только то что с ней совпадает ;-)

>То есть, в кейсе у вас нету непосредственно структуры таблиц? Нет >непосредственных связей одной таблицы с другой?
Да есть в минимально необходимом количестве. Ну есть сущность связаная с другими и есть у нее атрибуты не относящиеся к связям. Зачем они в CASE? Чтобы в 2 местах поддерживать?

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

>Тогда каким образом составляется общий скрипт развертывания базы?
Не составляется. Он не нужен

>В твоем случае проще сравнить девелоперскую БД с БД предыдущей >версии и получить скрипты непосредственно перехода. Перехватывая DDL >вы еще и таким образом формируете историю изменения метаданных. >Простой пример, завели табличку, потом поняли что не нужна - дропнули. >При сравнении эталона с девелоперской ничего и не будет, в вашем >подходе вы перехватите CREATE TABLE, а потом ее DROP.
Ну да. И что? Зато в любой момент можно создать базу со структурой которая была вообще в произвольный момент времени в прошлом.

Вообще все выглядит так: есть база разработки и есть база для тестирования и есть продакшн база (причем несколько - логические standby)

Все что есть в тестовой является неким "псевдоэталоном" разработчик не может ничего делать с любым объектом в девелоперской базе если этот объект есть в тестовой базе.

Реализован некий собственный аналог VSS когда чтобы изменить объект в девелоперской базе нужно сначала его пометить в тестовой как модифицируемый. Разработчик "берет" объект (ы) и работает с ними. То чего нет в тестовой базе - является свободным с ним можно делать что угодно. Когда разработчик закончил определенный этам он "коммитит" свои изменения (в том числе указывая какие новые объекты созданные им нужно включить в систему контроля).
После этого изменения (только те которые сказал разработчик - фактически за его подписью) переносятся на тестовый сервер и за них берется отдел тестирования. Если они ничего плохого не нашли - изменения накатываются на продакшн ферму.

>импорт экспорт чего? Не понимаю о чем ты говоришь...
Ну вот того что наделали. Допустим хотим сделать эталонную базу такого-то релиза. Берем проигрываем DDL и получаем базу. На нее накатываем DML - получаем эталон с заполненой системной инфой. Потом делаем экспорт - получаем дамп - отдаем кому надо. Ноу проблем.

← →
bss (2010-10-22 19:53) [44]

Sergey Masloff, очень интересно, начинаю понимать. Есть вопросы:

- каким образом запрещается редактирование объектов в девелоперской базе, которые есть в тестовой базе? Тригеры на схемы, внедрение какой-то своей контрольной системы?

- какими средствами работаете с БД? Например, в Oracle по аккаунту могут зайти много человек, как проверяется что это именно тот разработчик, который пометил объект на модификацию и соответственно ему разрешено это право?

- как я понимаю, отслеживание DDL реализовано на тестовом сервере?

> После этого изменения (только те которые сказал разработчик
> - фактически за его подписью) переносятся на тестовый сервер
> и за них берется отдел тестирования

разработчик выдает DDL-скрипт?

Как вы решаете проблему с неправильными действиями? То есть, разработчик, допустим, решил DROP"нуть таблицу (условный пример), посчитав, что она не нужна. Или в конце концов просто ошибся с именем, скопипастил не туда - всякое бывает. Таблица дропнулась, вылезли косяки.

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

← →
Sergey Masloff (2010-10-22 20:12) [45]

bss (22.10.10 19:53) [44]
>- каким образом запрещается редактирование объектов в девелоперской >базе, которые есть в тестовой базе? Тригеры на схемы, внедрение какой->то своей контрольной системы?
Просто триггер на уровне базы

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

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

>разработчик выдает DDL-скрипт?
Нет. Он в клиенте (не оракловском, наш самописный клиент) помечает что вот эти объекты которые он "брал" он хочет "выложить" (или "отменить взятие"). Также в этом клиенте он помечает новые объекты которые он создал в рамках этой задачи и которые нужны на тестовом сервере. Фактически в списке ему даются все объекты сервера разработки которых нет на сервере тестирования. Он выбирает "свои" но не все а только "не мусорные"

Потом администратор нажимает кнопель в час "X" система бежит по всем объектам помеченым к выкладке определяет что нужно "проиграть" и накатывает.

>DROP"нуть таблицу (условный пример), посчитав, что она не нужна.
Для этого ему нужно "взять" ее с тестового сервера. Если он ее дропнул, ее можно просто "взять" снова. Так что тут еще проще никакой хронологии не нужно.

Дропнуть таблицу на сервере тестирования или боевом не может никто (по крайней мере ни у кого из разработчиков нет туда доступа)

← →
Игорь Шевченко © (2010-10-22 21:59) [46]

bss (22.10.10 19:53) [44]

Тебе все чтоб трескотня была и умные слова. Проще надо быть :) Обычно вырабатывается набор неких внутрикомандных соглашений, кто что где когда и зачем изменяет, с возможностью отката изменений или отрывания рук. Так как рук жалко, то стараются делать так, чтобы можно было откатить тем или иным способом, а не так, что существует помойка, куда каждый пихает в произвольный момент времени, что ни попадя, а потом испольуется куча навороченных систем, чтобы за этой помойкой следить. Кроме всего прочего, у СУБД достаточно средств, чтобы по ним отследить, когда и кто ее поменял, после этого вопрос "зачем" можно задать конкретному автору изменений. Ну или руки ему оторвать по самую голову.

← →
bss (2010-10-22 22:26) [47]

> То есть берет не просто конкретный разработчик а конкретный
> разработчик на конкретную рабочую станцию.

то есть, разрешение идет на конкретный IP компьютера?
Насчет идентификации разработчика не понял, коли они все сидят под одним акком (у нас также).

> Потом администратор нажимает кнопель в час "X" система бежит
> по всем объектам помеченым к выкладке определяет что нужно
> "проиграть" и накатывает.

ммм... То есть, система бежит по всем помеченным как модифицированные объектам, сверяет с тестовыми объектами и соответствующим образом изменяет структуру в объекте на тестовом сервере?
Определяет какие колонки добавились, какие удалились, как изменились FK, какие появились новые комментарии и так далее?
Навороченная самописная программа получается... А во сколько ты оценил бы время разработки такой системы контроля версий для БД?

> Для этого ему нужно "взять" ее с тестового сервера. Если
> он ее дропнул, ее можно просто "взять" снова

"взять" - это типа как заблокировать в системе контроля версий? Ок... Дальше он делает Drop на девелоперской базе. Дальше делает чекин в СКВ... Реально таблица не дропается на тестовой базе?

И что значит можно снова взять? Если он пытается лочить объект в тестовой базе, а его при этом нет в девелоперской - он пересоздается в девелоперской?

И вообще, я подумал, что если ты залочил существующий в тестовой базе объект, изменил его в девелоперской, потом зачекинил - то изменения в это время и переносятся в тестовую базу?

Сори, опять потерял нить принципа работы...

← →
Sergey Masloff (2010-10-22 22:46) [48]

bss (22.10.10 22:26) [47]
>то есть, разрешение идет на конкретный IP компьютера?
>Насчет идентификации разработчика не понял, коли они все сидят под >одним акком (у нас также).
Ну IP или имя станции какая разница. Собственно говоря "checkout" это запись в системной таблице (в другой схеме не относящейся к предметной области). Модификация данных в этой таблице (как и во всех остальных) только персонифицированная. Для этого используется фактически переменная пакета. Установить ее напрямую нельзя а только вызвав функцию в которую передается имя и пароль. Пока функция не выполнилась успешно - переменная неинициирована и системный триггер не дает модифицировать вообще никакие данные. Вобщем все персонифицировано

>То есть, система бежит по всем помеченным как модифицированные >объектам, сверяет с тестовыми объектами и соответствующим образом >изменяет структуру в объекте на тестовом сервере?
Нет сверять ничего не нужно - они изначально одинаковые, просто прогоняются DDL которые делались по этому объекту с момента "взятия"

>"взять" - это типа как заблокировать в системе контроля версий? Ок... >Дальше он делает Drop на девелоперской базе. Дальше делает чекин в >СКВ... Реально таблица не дропается на тестовой базе?
Если сделал CheckIn - дропается. Но тогда обломится тестирование и объект потом восстановится с продакшн базы - на продакшн ничего не дропается пока туча проверок не пройдет. Если дропнется то восстановить все равно можно просто дольше - все же DDL сохранены...

>И вообще, я подумал, что если ты залочил существующий в тестовой базе >объект, изменил его в девелоперской, потом зачекинил - то изменения в >это время и переносятся в тестовую базу?
Ну почти. У нас "CheckIn" это понятие логическое - просто сигнал администратору что на момент очередной "сборки" это должно уйти на тестовую базу. Пока администратор не нажмет кнопку ничего не произойдет - это ж базу в рестриктед нужно переводить и много чего еще...

А так вроде все правильно ты понял ;-)

← →
xayam © (2010-10-23 00:04) [49]

> bss (22.10.10 18:20) [41]
> > Хотите сказать то, что Вы делаете и то, что получается
> > в принципе не одно и то же?
> не понял вопроса

по-моему достаточно точно сформулировано.
То, что Вы моделируете у себя и то, что получается после внедрения - это не одно и то же? И Вы не можете это никак проверить в автоматическом режиме?

> > друпал твоё всё, там это уже давно решено: и установка,
> > и модификация, и выполнение "долгих" "удалённых" инсталляций.
> это какой-то модуль к какой-то CMS системе как я понял.
> Как это связано с задачей?

"какая-то" cms, "какой-то" модуль, "какой-то" php, "какой-то" unix... ;)

> Или там реализованы какие-то принципы? Можно рассказать
> тогда об этим принципах?

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

← →
bss (2010-10-23 14:12) [50]

> Ну IP или имя станции какая разница. Собственно говоря "checkout"
> это запись в системной таблице

ясно... В принципе, аутентификация по IP - это вариант. Но некоторые БД могут лежать вне локальной сети и чисто технически получится, что доступ от РАЗНЫХ разработчиков с разных компов будет идти с одного IP. Конечно, ситуация не такая уже распространенная. Это один разработчик должен сделать чекаут, а другой в этой БД изменить объект, операция пройдет и запишется на имя первого разработчика...

Также при наличии нескольких серверов интересно, а где хранить собственно журнал DDL операций?

> просто прогоняются DDL которые делались по этому объекту
> с момента "взятия"

а как поступаете с ссылками, например? Child -> Parent table - к какой таблице считается привязанным? Подозреваю, что к Child.
И что делать, если в СКВ я добавил таблицу Child, а Parent не стал добавлять? Тогда возникнет исключение в последовательности DDL операций на тестовой базе... А если учесть, что эти операции не транзакционны - надо лезть в хронологию DDL-операций и что-то ручками править?
В этом и есть проблема, что-то там в прошлом ковыряться в мегабайтах скриптах - утопичное дело...

> Но тогда обломится тестирование и объект потом восстановится
> с продакшн базы

да, восстановится, но каким образом?

Чтобы восстановить DROP"нутую таблицу тебе нужно:

1) создать ее со всеми параметрами типа индексов и прочее.
2) протянуть все существовашие FK
3) наполнить ее данными

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

← →
bss (2010-10-26 23:09) [51]

А кто-нибудь знает готовые системы контроля версий для разработки под БД, в частности, Oracle?

← →
bss (2010-11-14 16:59) [52]

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

Весело тут у вас.
Оарэмщиков скоро реально будут пинать ногами, как гербалайфщиков.

Проектирование БД Найти похожие ветки