Добавил себе в закладки, поскольку сейчас параллельно с основной веткой разработки нашего проекта на Delphi начата работа над .Net вариантом.
К слову, наш проект работает с двумя базами: Oracle и Firebird. И если изменения в физической структуре БД Oracle почти всегда осуществимы, в худшем случае зависимые объекты станут (возможно, на время, до последующих команд миграции) инвалидными — это всегда можно поправить, перекомпилировав по окончании миграции основные схемы своей БД, то в Firebird все не так просто. Наличие зависимых объектов просто не позволит выполнить ряд операций (например, у нас предустматриваются по три view на каждую таблицу (для выборки, обновления и удаления, и уже на эти view раздаются права пользователям) и в подавляющем числе случаев выглядят как select * from ). В описанном мной случае нельзя будет поменять тип существующих полей таблицы, удалить существующие поля. Поэтому в нашей системе обновлений таблиц предусматривается полное устранения зависимостей перед началом операций и затем попытка их воссоздания (с перераздачей сохраненных перед удалением прав).
Возможно, по мере развития вашего мигратора вам придется столкнуться с Firebird. Рад буду помочь!
Data Mart — Витрина Данных, во всех встреченных мной проектах являлась составной частью хранилища данных (Data Warehouse). При этом хранилище данных гораздо более емкое, сложное понятие, формируется ETL джобами из разных (и разнородных) источников, но внутри себя после трансформации содержит уже унифицированную информацию. Как можно более полную, желательно. И по возможности приведенную к каким-либо промышленным стандартам вроде Basel II. После формирования хранилища (это может быть полная или, чаще, инкрементальная загрузка) уже и формируются витрины данных — кастомизированные, заточенные под реальные нужды клиентов, часто независимые друг от друга — отдельные блоки аналитической информации. Скажем, в банковском бизнесе — данные в хранилище общие по банку (клиенты, счета, транзакции и т.п.), а витрины разные — скажем, несколько витрин касаемо кредитного бизнеса, несколько — касаемо депозитного. то есть по разделам деятельности банка. И как правильно нарисовано на схеме Инмана, в дальнейшем по витринам строятся OLAP-отчеты, преобразующие многомерные кубы в понятные человеку отчеты, скажем, в своем веб-браузере. Я в ближайшее время опубликую в своем блоге первый свой хабратопик — статью о SAS Banking Intelligence Solution. Тогда приглашу оценить!
Согласен, что из таких модулей надо уметь быстро состыковать ночлежку для нужного числа людей. А вообще в идеале, как мне кажется, нужно чтобы получалось типа спальных вагонов, то есть предусмотреть санитарные модули, общий выход и курилку (она же — запасный выход). На случай зимы подключаем к «вагону» модуль с печкой, на случай жаркого лета меняем его на модуль с кондиционером. Тогда, конечно, образуется некое пустое место для транзитного прохода, и не очень понятен становится отдельно стоящий модуль.
К слову, наш проект работает с двумя базами: Oracle и Firebird. И если изменения в физической структуре БД Oracle почти всегда осуществимы, в худшем случае зависимые объекты станут (возможно, на время, до последующих команд миграции) инвалидными — это всегда можно поправить, перекомпилировав по окончании миграции основные схемы своей БД, то в Firebird все не так просто. Наличие зависимых объектов просто не позволит выполнить ряд операций (например, у нас предустматриваются по три view на каждую таблицу (для выборки, обновления и удаления, и уже на эти view раздаются права пользователям) и в подавляющем числе случаев выглядят как select * from ). В описанном мной случае нельзя будет поменять тип существующих полей таблицы, удалить существующие поля. Поэтому в нашей системе обновлений таблиц предусматривается полное устранения зависимостей перед началом операций и затем попытка их воссоздания (с перераздачей сохраненных перед удалением прав).
Возможно, по мере развития вашего мигратора вам придется столкнуться с Firebird. Рад буду помочь!