Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
Кто-нибудь использует?
Раньше с таким не сталкивался, на корабле всегда только 1 капитан, и в проектах был всегда 1 архитектор, он контролировал схему, через него шли все согласования. А сейчас есть две команды с возможностью изменения схемы.

Git не подходит, там только файлы DDL, а нужно чтобы было управление не на уровне текста скрипта, а на уровне сущности БД, на уровне поля, если кто-то меняет его название, тип, размер, коммент, запускалась бы процедура согласования/уведомления, а заинтересованные сотрудники могли бы подписываться на изменения, чтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли.
13 июн 18, 12:48    [21488076]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 4009
Sintetik, я не встречал. Обычно регулируется процессом:
-разделяется на 2 базы: тестовая, рабоая
-у рабочей базы отбирают права на изменение у всех сотрудников, кроме 1-2 ответственных
-они уже делают магию

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

Процесс примерно такой:
1) Кто-то хочет изменить схемы
2) Изменяет схему liqubase
3) Создает пул реквест на гитхабе
4) Ответственное лицо - проверяет и апрувит пул реквест
5) Ответственные специалисты получают уведомления о том, что в их ветку там заапрувили что-то - накатывают изменения.
13 июн 18, 13:22    [21488176]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Sintetik
а на уровне сущности БД, на уровне поля, если кто-то меняет его название, тип, размер, коммент, запускалась бы процедура согласования/уведомления, а заинтересованные сотрудники могли бы подписываться на изменения, чтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли.


Готовых решений не встречал. Когда то тоже пытался отслеживать такие изменения в Oracle. Выход был-сделал триггер на схеме и отписывал изменения в отдельные таблицы.
13 июн 18, 13:24    [21488184]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
hVostt
Member

Откуда:
Сообщений: 13588
Sintetik,

Миграции не пробовали? Миграция это и DDL и DML, в контексте обновления версии. Пока разработка идёт, каждый создаёт свои маленькие миграции, а при стабилизации версии, миграции объединяются, инспектируются, накатываются на тест и т.д. и т.п.

Пока идёт разработка -- не нужен жёсткий контроль, хотя общаться нужно всё время и согласовывать свои изменения.
13 июн 18, 13:36    [21488222]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
hVostt
Sintetik,

Миграции не пробовали? Миграция это и DDL и DML, в контексте обновления версии. Пока разработка идёт, каждый создаёт свои маленькие миграции, а при стабилизации версии, миграции объединяются, инспектируются, накатываются на тест и т.д. и т.п.

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


Любые чисто технически решения на уровне БД не пройдут, это мало того что разные сервера, но еще и разные вендоры БД, хотя схемы идентичные, почти. Поэтому разные команды, и невозможность решить проблему административно.
задача минимум нужно хотя бы вовремя получать уведомления об изменениях в схеме, ДО того как их накатят
вторая задача получать уведомления о расхождениях в схемах, раз уж накатили, в идеале со скриптом различий
13 июн 18, 13:45    [21488248]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Sintetik
чтобы получать уведомление - таблица поменялось, добавилось поле, изменилась связь между такими то таблицами и тп, а не просто DDL скрипт поменяли.


еще по своему опыту сделал вывод: согласовывать изменения структуры лучше до внесения изменений в саму БД. В erwin делаешь проект изменений- выкладываешь картинки (или можно экспорт в html делать с возможностью навигации) на wiki или где угодно обсуждаешь. Пришли к общему решению - вносишь изменения в БД.
Для этого желательно чтобы был один администратор схемы БД, который бы знал базу от и до.
13 июн 18, 13:49    [21488268]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
hVostt
Member

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


Понял, миграций у вас нет.
Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может

Нельзя автоматизировать бардак.
13 июн 18, 13:52    [21488284]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
hVostt
Понял, миграций у вас нет.
Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может
Нельзя автоматизировать бардак.

идет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL? поэтому нужно оперировать в логических сущностях
13 июн 18, 16:28    [21488951]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Sintetik
hVostt
Понял, миграций у вас нет.
Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может
Нельзя автоматизировать бардак.

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

Разный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему?
13 июн 18, 16:36    [21488977]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Кот Матроскин
Разный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему?


Если разные вендоры, то придется Erwin схему для каждого вендора хранить. В любом случае автоматически синхронизировать изменения не получится. Тем более если такой бардак, когда несколько команд разработчиков вносят изменения в базу независимо друг от друга.
13 июн 18, 16:50    [21489026]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 2897
Sintetik,

Не получится.

Сделайте 2 базы, по одной на команду. Каждая команда рулит своей базой, как хочет.

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

Все остальные варианты подразумевают безупречное следование орг. процессу, что на практике всегда будет выливаться в бардак, а он не автоматизируем.
13 июн 18, 17:02    [21489061]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Serguei
Кот Матроскин
Разный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему?


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

Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров.
Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :)
Serguei
В любом случае автоматически синхронизировать изменения не получится. Тем более если такой бардак, когда несколько команд разработчиков вносят изменения в базу независимо друг от друга.

Почему? Erwin-модель в этой схеме - точно такой же программный модуль, который точно так же лежит в source control,
точно так же checkout-ится, как все остальные, не вижу никакой специфики.
13 июн 18, 17:15    [21489085]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Кот Матроскин
Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров.
Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :)

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

Кот Матроскин
Почему? Erwin-модель в этой схеме - точно такой же программный модуль, который точно так же лежит в source control,
точно так же checkout-ится, как все остальные, не вижу никакой специфики.

Из вышесказанного -это две разных модели, поэтому.
13 июн 18, 17:25    [21489112]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Serguei
Кот Матроскин
Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров.
Вообще разделение на логическую и физическую модели придумано и поддерживается соответствующими тулами уже 20+ лет не просто так :)

Теоретически да, практически нет. Типы данных разные. Для одной логической схемы ервин не позволяет сделать несколько физических. Это разные модели.

Даже если так (не помню, честно говоря) - можно вносить изменения строго в одну модель, а вторую получать из нее копированием с переключением вендора и перестройкой физмодели.
13 июн 18, 17:30    [21489128]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Кот Матроскин
Даже если так (не помню, честно говоря) - можно вносить изменения строго в одну модель, а вторую получать из нее копированием с переключением вендора и перестройкой физмодели.


Сначала попробуйте, потом совет давайте ;-)
Тип данных не всегда однозначно конвертируется. Каждый раз придется перелопачивать и руками менять типы данных у полей.
13 июн 18, 17:58    [21489193]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Serguei
Тип данных не всегда однозначно конвертируется.

Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy.
13 июн 18, 18:23    [21489256]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 533
Кот Матроскин
Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy.


Отличная идея!
Как быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных?
13 июн 18, 19:57    [21489393]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
hVostt
Member

Откуда:
Сообщений: 13588
Sintetik
идет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL? поэтому нужно оперировать в логических сущностях


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

В общем, я конечно всех подробностей не знаю, но пока что выглядит это так. Мы гребём вилами, и пока не очень получается быстро плыть. Что нам делать? Весло не советовать.
13 июн 18, 20:26    [21489437]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
hVostt
Member

Откуда:
Сообщений: 13588
Кот Матроскин
Serguei
Если разные вендоры, то придется Erwin схему для каждого вендора хранить.

Как раз нет - Erwin вполне может, имея одну и ту же логическую модель, сформировать разные DDL для разных вендоров.


Учитывая сказанное про Erwin, советовать весло для гребли бессмысленно. Нужны какие-то особые магические насадки на вилы, чтобы оно как-то само всё стало хорошо
13 июн 18, 20:27    [21489441]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
hVostt
Member

Откуда:
Сообщений: 13588
Serguei
Тип данных не всегда однозначно конвертируется. Каждый раз придется перелопачивать и руками менять типы данных у полей.


Тип данных это самое наименьшое зло, которое можно найти в поддержке более одного вендора. Примерно размером с комара.
13 июн 18, 20:28    [21489448]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Serguei
Кот Матроскин
Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy.


Отличная идея!
Как быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных?


Ээ, я правильно понял вопрос - как человеку рулить изменениями разных баз из одной логической схемы, не приводя базы к этой схеме?
13 июн 18, 20:38    [21489470]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
Кот Матроскин
Serguei
Тип данных не всегда однозначно конвертируется.

Если стоит задача поддерживать несколько вендоров по одной логической модели - не надо использовать типы данных, которые "не всегда однозначно конвертируются", that easy.

типы обычные скалярные, без экзотики, именно поэтому
14 июн 18, 16:18    [21491425]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
Serguei
Как быть человеку, у которого уже есть две разных базы и вряд ли кто-то думал о соответствии типов данных?

думали, соответствие типов обеспечивается, т.к. базы синхронизируются внешней ETL тулзой, причем в обе стороны
14 июн 18, 16:19    [21491434]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Sintetik
Member

Откуда: SpB->Msk->...
Сообщений: 8675
Кот Матроскин
Ээ, я правильно понял вопрос - как человеку рулить изменениями разных баз из одной логической схемы, не приводя базы к этой схеме?

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

причем я не уверен, что получится ту команду напрячь вести схему в тулзе, и сначала делать изменения в тулзе, и только потом применять их на базе, поэтому хорошо бы чтобы тулза могла регулярно опрашивать ту схему и показывать дифференс с нашей и делать рассылку. Ну и само собой инстансов больше чем 1, тест/дев/
14 июн 18, 16:29    [21491465]     Ответить | Цитировать Сообщить модератору
 Re: Система управления изменениями в схеме БД  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 7990
Sintetik

причем я не уверен, что получится ту команду напрячь вести схему в тулзе, и сначала делать изменения в тулзе, и только потом применять их на базе, поэтому хорошо бы чтобы тулза могла регулярно опрашивать ту схему и показывать дифференс с нашей и делать рассылку. Ну и само собой инстансов больше чем 1, тест/дев/


Это может делать несложный отчет, я даже сомневаюсь что внедрение полноценного data modeller'а конкретно для этого имеет смысл - но откуда Вы планируете получать причины дифференса (предзназначение новых полей, и т.п.)?
И если Вы хотите сравнивать не с продом, а с тестом/дев-ом - что Вы будете делать с "фантомами" (чтобы постестить подход, создали табличку, результаты не понравились - на следующий день убили)?
Коллеги выше Вам верно намекают - у вас в первую административная проблема. А решать административные проблемы при помощи только техсредств - достаточно бесперспективный путь.
14 июн 18, 16:47    [21491520]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить