SintetikhVosttПонял, миграций у вас нет.
Просто.. кто-то как-то когда-то почему-то что-то там накатывает, потому что может
Нельзя автоматизировать бардак.
идет разработка, активная, но параллельно на двух разных базах, кто будет приводить разный синтаксис в DDL?
поэтому нужно оперировать в логических сущностях
Разный синтаксис в DDL "приводят" обычно средства типа Erwin. Почему бы не хранить в репозитории erwin-схему?

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

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

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

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

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

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

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

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

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

Это может делать несложный отчет, я даже сомневаюсь что внедрение полноценного data modeller'а конкретно для этого имеет смысл - но откуда Вы планируете получать причины дифференса (предзназначение новых полей, и т.п.)?
И если Вы хотите сравнивать не с продом, а с тестом/дев-ом - что Вы будете делать с "фантомами" (чтобы постестить подход, создали табличку, результаты не понравились - на следующий день убили)?
Коллеги выше Вам верно намекают - у вас в первую административная проблема. А решать административные проблемы при помощи только техсредств - достаточно бесперспективный путь.