Репликация структуры базы

← →
Pul (2004-05-27 13:18) [0]

Теоретический вопрос.
Корректно ли пытаться перенести структуру с одной базы на другую простой сихронизацией данных в соответствующих системных таблицах?

← →
Курдль © (2004-05-27 14:20) [1]

Однозначно не корректно! А вот можно ли вообще...
Есть полная уверенность в видимости для каких угодно крутых пользователей всех таблиц? А вдруг что-то скрыто?

← →
Pul (2004-05-27 14:28) [2]

>> Курдль © (27.05.04 14:20) [1]
Для SYSDBA видно все.
Просто у меня регулярно возникают проблемы с переносом изменений структуры базы на машину клиента. Решил написать что-то свое для автоматизации этого процесса. Может подскажете какие-либо идеи. Одним из вариантов является навешивание триггеров на системные таблицы. Может существуют и другие способы. Гораздо приятнее было бы просто перехватывать SQL запросы на изменение структуры базы. Возможно ли это?

← →
HSolo © (2004-05-27 15:11) [3]

В IBExpert-е есть Database Comparer - сравнивает указанные базы и генерит скрипт для приведения структуры target-базы в соответствие с master-базой. Не оно?

← →
Курдль © (2004-05-27 15:37) [4]

> Просто у меня регулярно возникают проблемы с переносом изменений
> структуры базы на машину клиента. Решил написать что-то
> свое для автоматизации этого процесса. Может подскажете
> какие-либо идеи. Одним из вариантов является навешивание
> триггеров на системные таблицы. Может существуют и другие
> способы. Гораздо приятнее было бы просто перехватывать SQL
> запросы на изменение структуры базы. Возможно ли это?

Я не понимаю бизнес-логику Вашего "производственного процесса" :(

Что значит "Гораздо приятнее было бы просто перехватывать SQL
запросы на изменение структуры базы"? Вы что, не помните, что сотворили с БД?

Обычно создается проект БД, включающий в себя модели, скрипты создания и модификации. Изменил структуру - написал alter-скрипт - прогнал на БД клиента - утвердил версию.

Или у Вас полтергейст занимается модификацией структуры БД?

← →
Pul (2004-05-27 15:47) [5]

>> Курдль © (27.05.04 15:37) [4]
>> Я не понимаю бизнес-логику Вашего "производственного процесса" :(

Процесс совершенствования или дополнения программного продукта новыми функциями иногда влечет к изменению структуры базы данных.
Вот и вся логика

>>Обычно создается проект БД, включающий в себя модели, скрипты создания и модификации. Изменил структуру - написал alter-скрипт - прогнал на БД клиента - утвердил версию.

Абсолютно согласен. Просто я делаю не одно изменение с момента предыдущего релиза до нового. Запомнить что и когда я менял довольно трудно. Поэтому я хотел написать програмку, которая бы сравнивала структуры двух баз данных и генерировала скрипт для модификации.

← →
Курдль © (2004-05-27 15:59) [6]

> Поэтому я хотел написать програмку, которая бы сравнивала
> структуры двух баз данных и генерировала скрипт для модификации.

Дело Ваше, но я бы лучше записывал карандашом в журнальчик (с бумажными такими листочками) все изменения, а потом генерил один скрипт. Тем самым избавил бы себя от геморроя, связанного с созданием и использованием "искуственного интеллекта". :)

← →
Pul (2004-05-27 16:06) [7]

Еще у кого-нибудь, кроме Курдль есть идеи?

← →
slgeo © (2004-05-27 16:11) [8]

А вариант HSolo © не устраивает?

← →
Pul (2004-05-27 16:48) [9]

>> slgeo © (27.05.04 16:11) [8]
В (27.05.04 14:28) [2] я дал понять, что хочу это сделать программно.

← →
slgeo © (2004-05-27 16:55) [10]

Как вариант:
Можно перехватывать запросы SQL-монитором (причем на каждом клиенте), затем фильтровать и сохранять в какой-либо таблице.

ой, извняйте, спутал синхронизацию данных с синхронизацией структуры

Я видел нечто подобное в какой-то статье на ibase.ru. Триггеры навешивались на системные талицы, а потом из получившегося журнала генерировался скрипт (уже DML) для модификации структур бызы. Я не рискнул этим чужим продуктом воспользоваться, хотя саму идею не считаю идиотской. Она ровно настолько же идиотская или неидиотская, как и любая обычная репликация данных. Может быть даже она лучше, чем обычная репликация данных, так как в данном случае база-источник изменений одна и разработчик один. При репликации данных, когда одни удаляют то, на что ссылаются другие, которые в этот момент что-то вводят, гораздо чреватее ошибками и логическими тупиками.
Так что нужно попробовать такую вещь реализовать и я не думаю, что это так уж сложно. Единственное, о чем сразу хочу предупредить - система триггеров должна еще уметь восстанавливаться после backup/restore базы. Пользовательские триггеры, навешенные на системные таблицы, насколько мне известно, при стандартном backup/restore теряются. Так что это самое узкое место, ИМХО. А вообще идея сама по себе - правильная.

Кстати, мне тоже интересно, что из этого получится. Так что если сделаете что-нибудь - дайте мне тоже знать, если не трудно.
:)

а что мешает в том же IBExpert при разработке включить лог всех изменений и получившийся скрипт потом вливать на рабочую БД?
Хотя я обычно веду скрипт изменений вручную (это не так и сложно), а потом перед отбыванием к клиенту для внесения изменений беру БД с последним вариантом структуры, проганяю на ней скрипт и Database Comparer-ом из IBExpert сравниваю получившуюся БД с БД которая подвергалась иземениям разработчика. При нормальном исходе между ними не должно быть разницы

← →
Denis___ (2004-05-29 11:37) [15]

kombat © (28.05.04 00:13) [14]
Полностью согласен, только DataBase Comparer штука довольно тяжелая и глючная, Поскольку на базе размером 150-200М вываливается из за нехватки памяти машины(512М). Рекомендовал бы пользоваться IBComparer-ом. Все просто летает..

Репликация структуры базы Найти похожие ветки