|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кто-нибудь использует? Раньше с таким не сталкивался, на корабле всегда только 1 капитан, и в проектах был всегда 1 архитектор, он контролировал схему, через него шли все согласования. А сейчас есть две команды с возможностью изменения схемы. Git не подходит, там только файлы DDL, а нужно чтобы было управление не на уровне текста скрипта, а на уровне сущности БД, на уровне поля, если кто-то меняет его название, тип, размер, коммент, запускалась бы процедура согласования/уведомления, а заинтересованные сотрудники могли бы подписываться на изменения, чтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 12:48 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik, я не встречал. Обычно регулируется процессом: -разделяется на 2 базы: тестовая, рабоая -у рабочей базы отбирают права на изменение у всех сотрудников, кроме 1-2 ответственных -они уже делают магию В вашем случае, можно добавить - миграцию баз данных осуществлять с помощью liqubase , схемы которого которые можно уже засовывать в любой репозиторий с любыми хуками. А эти 1-2 специалиста будут что-то делать только после approved pull request`а. Процесс примерно такой: 1) Кто-то хочет изменить схемы 2) Изменяет схему liqubase 3) Создает пул реквест на гитхабе 4) Ответственное лицо - проверяет и апрувит пул реквест 5) Ответственные специалисты получают уведомления о том, что в их ветку там заапрувили что-то - накатывают изменения. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:22 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetikа на уровне сущности БД, на уровне поля, если кто-то меняет его название, тип, размер, коммент, запускалась бы процедура согласования/уведомления, а заинтересованные сотрудники могли бы подписываться на изменения, чтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли. Готовых решений не встречал. Когда то тоже пытался отслеживать такие изменения в Oracle. Выход был-сделал триггер на схеме и отписывал изменения в отдельные таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:24 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik, Миграции не пробовали? Миграция это и DDL и DML, в контексте обновления версии. Пока разработка идёт, каждый создаёт свои маленькие миграции, а при стабилизации версии, миграции объединяются, инспектируются, накатываются на тест и т.д. и т.п. Пока идёт разработка -- не нужен жёсткий контроль, хотя общаться нужно всё время и согласовывать свои изменения. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:36 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
hVosttSintetik, Миграции не пробовали? Миграция это и DDL и DML, в контексте обновления версии. Пока разработка идёт, каждый создаёт свои маленькие миграции, а при стабилизации версии, миграции объединяются, инспектируются, накатываются на тест и т.д. и т.п. Пока идёт разработка -- не нужен жёсткий контроль, хотя общаться нужно всё время и согласовывать свои изменения. Любые чисто технически решения на уровне БД не пройдут, это мало того что разные сервера, но еще и разные вендоры БД, хотя схемы идентичные, почти. Поэтому разные команды, и невозможность решить проблему административно. задача минимум нужно хотя бы вовремя получать уведомления об изменениях в схеме, ДО того как их накатят вторая задача получать уведомления о расхождениях в схемах, раз уж накатили, в идеале со скриптом различий ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:45 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetikчтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли. еще по своему опыту сделал вывод: согласовывать изменения структуры лучше до внесения изменений в саму БД. В erwin делаешь проект изменений- выкладываешь картинки (или можно экспорт в html делать с возможностью навигации) на wiki или где угодно обсуждаешь. Пришли к общему решению - вносишь изменения в БД. Для этого желательно чтобы был один администратор схемы БД, который бы знал базу от и до. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:49 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SintetikЛюбые чисто технически решения на уровне БД не пройдут, это мало того что разные сервера, но еще и разные вендоры БД, хотя схемы идентичные, почти. Поэтому разные команды, и невозможность решить проблему административно. задача минимум нужно хотя бы вовремя получать уведомления об изменениях в схеме, ДО того как их накатят вторая задача получать уведомления о расхождениях в схемах, раз уж накатили, в идеале со скриптом различий Понял, миграций у вас нет. Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может Нельзя автоматизировать бардак. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 13:52 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
hVosttПонял, миграций у вас нет. Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может Нельзя автоматизировать бардак. идет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL? поэтому нужно оперировать в логических сущностях ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 16:28 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SintetikhVosttПонял, миграций у вас нет. Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может Нельзя автоматизировать бардак. идет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL? поэтому нужно оперировать в логических сущностях Разный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 16:36 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинРазный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему? Если разные вендоры, то придется Erwin схему для каждого вендора хранить. В любом случае автоматически синхронизировать изменения не получится. Тем более если такой бардак, когда несколько команд разработчиков вносят изменения в базу независимо друг от друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 16:50 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik, Не получится. Сделайте 2 базы, по одной на команду. Каждая команда рулит своей базой, как хочет. Если нужны какие-то данные друг от друга, вводите абстрагирующую прослойку в виде вьюх / функций, которые доступны соседу для чтения. Их интерфейс должен быть фиксирован, кто сломал, тот и чинит. Все остальные варианты подразумевают безупречное следование орг. процессу, что на практике всегда будет выливаться в бардак, а он не автоматизируем. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 17:02 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiКот МатроскинРазный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему? Если разные вендоры, то придется Erwin схему для каждого вендора хранить. Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров. Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :) Serguei В любом случае автоматически синхронизировать изменения не получится. Тем более если такой бардак, когда несколько команд разработчиков вносят изменения в базу независимо друг от друга. Почему? Erwin-модель в этой схеме - точно такой же программный модуль, который точно так же лежит в source control, точно так же checkout-ится, как все остальные, не вижу никакой специфики. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 17:15 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинКак раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров. Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :) Теоретически да, практически нет. Типы данных разные. Для одной логической схемы ервин не позволяет сделать несколько физических. Это разные модели. Субд выбирается целиком для модели. Кот МатроскинПочему? Erwin-модель в этой схеме - точно такой же программный модуль, который точно так же лежит в source control, точно так же checkout-ится, как все остальные, не вижу никакой специфики. Из вышесказанного -это две разных модели, поэтому. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 17:25 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiКот МатроскинКак раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров. Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :) Теоретически да, практически нет. Типы данных разные. Для одной логической схемы ервин не позволяет сделать несколько физических. Это разные модели. Даже если так (не помню, честно говоря) - можно вносить изменения строго в одну модель, а вторую получать из нее копированием с переключением вендора и перестройкой физмодели. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 17:30 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинДаже если так (не помню, честно говоря) - можно вносить изменения строго в одну модель, а вторую получать из нее копированием с переключением вендора и перестройкой физмодели. Сначала попробуйте, потом совет давайте ;-) Тип данных не всегда однозначно конвертируется. Каждый раз придется перелопачивать и руками менять типы данных у полей. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 17:58 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiТип данных не всегда однозначно конвертируется. Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 18:23 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинЕсли стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy. Отличная идея! Как быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 19:57 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetikидет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL? поэтому нужно оперировать в логических сущностях Не понимать. Если базы разные, то что вы там тогда синкаете, непонятно? Разные в каком смысле? Разные вендоры? А схемы полностью одинаковые? И что, вы прям кодите DDL разных баз и пытаетесь содержать их соответствие? В общем, я конечно всех подробностей не знаю, но пока что выглядит это так. Мы гребём вилами, и пока не очень получается быстро плыть. Что нам делать? Весло не советовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 20:26 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинSergueiЕсли разные вендоры, то придется Erwin схему для каждого вендора хранить. Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров. Учитывая сказанное про Erwin, советовать весло для гребли бессмысленно. Нужны какие-то особые магические насадки на вилы, чтобы оно как-то само всё стало хорошо ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 20:27 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiТип данных не всегда однозначно конвертируется. Каждый раз придется перелопачивать и руками менять типы данных у полей. Тип данных это самое наименьшое зло, которое можно найти в поддержке более одного вендора. Примерно размером с комара. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 20:28 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiКот МатроскинЕсли стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy. Отличная идея! Как быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных? Ээ, я правильно понял вопрос - как человеку рулить изменениями разных баз из одной логической схемы, не приводя базы к этой схеме? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2018, 20:38 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинSergueiТип данных не всегда однозначно конвертируется. Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy. типы обычные скалярные, без экзотики, именно поэтому ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2018, 16:18 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiКак быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных? думали, соответствие типов обеспечивается, т.к. базы синхронизируются внешней ETL тулзой, причем в обе стороны ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2018, 16:19 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинЭэ, я правильно понял вопрос - как человеку рулить изменениями разных баз из одной логической схемы, не приводя базы к этой схеме? почти, если бы я контролировал обе базы, то проблемы бы не были, но я контролирую только одну, а во второй могут неожиданно для меня появиться/измениться/удалиться/ таблицы/поля/связи причем я не уверен, что получится ту команду напрячь вести схему в тулзе, и сначала делать изменения в тулзе, и только потом применять их на базе, поэтому хорошо бы чтобы тулза могла регулярно опрашивать ту схему и показывать дифференс с нашей и делать рассылку. Ну и само собой инстансов больше чем 1, тест/дев/ ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2018, 16:29 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik причем я не уверен, что получится ту команду напрячь вести схему в тулзе, и сначала делать изменения в тулзе, и только потом применять их на базе, поэтому хорошо бы чтобы тулза могла регулярно опрашивать ту схему и показывать дифференс с нашей и делать рассылку. Ну и само собой инстансов больше чем 1, тест/дев/ Это может делать несложный отчет, я даже сомневаюсь что внедрение полноценного data modeller'а конкретно для этого имеет смысл - но откуда Вы планируете получать причины дифференса (предзназначение новых полей, и т.п.)? И если Вы хотите сравнивать не с продом, а с тестом/дев-ом - что Вы будете делать с "фантомами" (чтобы постестить подход, создали табличку, результаты не понравились - на следующий день убили)? Коллеги выше Вам верно намекают - у вас в первую административная проблема. А решать административные проблемы при помощи только техсредств - достаточно бесперспективный путь. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2018, 16:47 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik хорошо бы чтобы тулза могла регулярно опрашивать ту схему и показывать дифференс с нашей и делать рассылку Если бы один вендор СУБД был- еще можно было бы отследить изменения. Revers Engineerig+Complit Compare и все. Но поскольку СУБД разные - практически все попадет в различия и каждый раз придется все таблицы просматривать. Короче не вариант ) Чтобы отследить такие изменения, самое простое что приходит на ум: сделать dblink и sql запросом делать сравнение объектов по системным таблицам. Если, конечно, такое ваши СУБД поддерживают. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.06.2018, 17:23 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiЕсли, конечно, такое ваши СУБД поддерживают. нет, это совсем разные системы, одна MPP платформа, вторая просто база ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2018, 19:13 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Кот МатроскинЭто может делать несложный отчет, я даже сомневаюсь что внедрение полноценного data modeller'а конкретно для этого имеет смысл - но откуда Вы планируете получать причины дифференса (предзназначение новых полей, и т.п.)? хотелось бы reverse, т.е. считаем истинной некую логическую схему, и узнаем насколько ей соответствуют текущие физические схемы если не соответствуют, то в чем разница Кот МатроскинИ если Вы хотите сравнивать не с продом, а с тестом/дев-ом - что Вы будете делать с "фантомами" (чтобы постестить подход, создали табличку, результаты не понравились - на следующий день убили)? в 95% случаев ничего не буду делать, у меня стоит задача синхронизации баз, причем моя система мастер в плане данных на 95% и синхронизация валится, только если создадут констрейнт на таблицу которой нет на моей стороне Кот Матроскин Коллеги выше Вам верно намекают - у вас в первую административная проблема. А решать административные проблемы при помощи только техсредств - достаточно бесперспективный путь. я в курсе кэп, вопрос был как решить вопрос технически, административно решат, но это как обычно не быстро, быстрее запилить уведомлялку если таковая существует ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2018, 19:18 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SintetikКот МатроскинЭто может делать несложный отчет, я даже сомневаюсь что внедрение полноценного data modeller'а конкретно для этого имеет смысл - но откуда Вы планируете получать причины дифференса (предзназначение новых полей, и т.п.)? хотелось бы reverse, т.е. считаем истинной некую логическую схему, и узнаем насколько ей соответствуют текущие физические схемы если не соответствуют, то в чем разница Ну тоже можно - сохраняете "сбоку" в какой-то момент, условно говоря, sysobjects выбранного прода, что-то правите, если надо, и считаете это "некоей логической схемой"(tm), с ней сравниваете физические схемы в последующие моменты. Держать эту схему в актуальном состоянии можно автоматической парсилкой накатываемых в рамках релизов DDL-ей, либо синхронизацией с физической структурой в "контрольных точках". SintetikКот МатроскинИ если Вы хотите сравнивать не с продом, а с тестом/дев-ом - что Вы будете делать с "фантомами" (чтобы постестить подход, создали табличку, результаты не понравились - на следующий день убили)? в 95% случаев ничего не буду делать, Мне-то все равно что Вы будете делать :) Если Вы проблему подхода осознаете, но считаете несущественной - ok ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2018, 20:14 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SergueiRevers Engineerig+Complit Compare и все. Ржу в голос. Резиновая кукла+Мультиварка и всё. Полностью заменяет женщину Компараторы не решают проблему миграций, никогда не решали, и никогда не будут. Но фантазировать никто помешать не может. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2018, 20:20 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
hVostt Ржу в голос. Резиновая кукла+Мультиварка и всё. Полностью заменяет женщину Компараторы не решают проблему миграций, никогда не решали, и никогда не будут. Но фантазировать никто помешать не может. Извините, но вы так громко ржали, что я не понял что вы сказали ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2018, 11:30 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
SintetikЛюбые чисто технически решения на уровне БД не пройдут, это мало того что разные сервера, но еще и разные вендоры БД, хотя схемы идентичные, почти. Поэтому разные команды, и невозможность решить проблему административно. задача минимум нужно хотя бы вовремя получать уведомления об изменениях в схеме, ДО того как их накатят вторая задача получать уведомления о расхождениях в схемах, раз уж накатили, в идеале со скриптом различий Если готового ничего нет, то надо самим вести модель, а БД генерировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2018, 13:22 |
|
Система управления изменениями в схеме БД
|
|||
---|---|---|---|
#18+
Sintetik, Такая проблема достаточно неплохо должна решаться силами метадата менеджеров. Создается единый бизнес-глоссарий, подцепляются различные источники, на периодической основе автоматически просматривается, не изменилось ли чего в источнике, также можно посмотреть, затрагивают ли эти изменения нужные нам бизнес сущности или нет, и рассылать уведомления. Хотел бы я сам замутить такое в продуктиве, но пока конечно же "дело нужное и важное, нам без этого никак, но сейчас есть задачи и поважнее" =) Насчет того, что Git не подходит, не совсем согласен. DDL скрипты очень неплохо там смотрятся, также на периодической основе можно собирать их с обеих баз, дать заинтересованным ссылку на bitbucket или gitlab по каждой базе, и рассылать, если есть изменения с текущей веткой. По уровню детализации и захвата изменений у Гита хорошее апи, можно хоть питоном сгенерировать нужные сообщения в почту (в такой то базе изменилось то и то в таком то месте). Неэнтерпрайзненько, но вполне себе работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2018, 10:50 |
|
|
start [/forum/topic.php?all=1&fid=32&tid=1540028]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
62ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
others: | 239ms |
total: | 414ms |
0 / 0 |