g_boxПодскажите плз, необходимо собирать данные в головную БД(Oracle) с удаленных (другой город, страна) БД более 10 (Access,Excel,Dbf,Oracle,MSSQL ...) как лучше это сделать например использовать гетерогенный сервис в Oracle (через ODBC)? или при помощи Web сервисов (Asp.Net) ? или что-то еще? Данные должны быть оперативными,каждые 30 минут. Может кто-то сталкивался с задачей подобного рода, буду благодарен за любую информацию и предложения! Спасибо.
IMHO лучше всего навести порядок и сделать гетерогенное гомогенным. Это окупится.

Не путайте гомогенность с централизованностью. Я говорил о гомогенности.

Если хранить информацию в БД под управлением различных СУБД - для N СУБД потребуется от 2*N (для архитектуры "звезда") до 2*N^2 (для архитектуры "полносвязный граф") "скриптов" для ETL. Не говоря уже о лишних интерфейсах пользователя, утилитах администрирования, лицензиях в конце концов :) . Не слишком ли дорого обойдётся создание и содержание такого зоопарка?

Я предлагаю хранить информацию в распределённой БД под управлением одной СУБД. Тогда можно будет решить задачу репликации встроенными средствами СУБД. И не понадобится постоянного использования ETL-платформы со "скриптами".

Что же касается распределённости - то в данном случае оптимистичная оценка необходимой пропускной способности канала между узлами распределённой БД в МБит вычисляется по формуле:

(максимально допустимое количество информации в БД в МБайт * 8) / (30 * 60 - время на извлечение, упаковку, распаковку и обновление в сек.) * степень сжатия при упаковке / эффективность канала

Т.е. при максимальном количестве информации в БД, равном 100 МБайт, нулевом времени на ETL, отсутствии сжатия и канале Ethernet с эффективностью 0.8 понадобится пропускная способность между двумя узлами "всего" около 0.6 Мбит.

При максимальном же количестве информации 10 ГБайт, и времени 20 мин. на их ETL, Вашего канала в 100 МБит не хватит.

iscrafm AlexTheRaven И не понадобится постоянного использования ETL-платформы со "скриптами".

понял "откуда ноги растут"...
Никаких принципов ETL. Пользователь инициирует изменение в одной БД, команды на изменение транслируются в команды для другой БД и передаются нужным адресатам.
Если ETL и подобное:
чтение-формирование входящего потока-преобразование потока-формирование исходящего потока-запись. Разницу улавливаете?
Честно сказать - не улавливаю. IMHO если есть БД 1 и БД 2, хранящие одну и ту же информацию в различных структурах, для репликации между ними без извлечения изменённой информации (Extraction), её трансформации к структуре целевой БД (Transformation) и загрузки (Loading) не обойтись. А выполнение операций в поточном (? разделения времени) режиме - не признак ETL.

iscrafm<...> Есть одна БД в которую пользователь вводит данные. То, что он вводит протоколируется и по нажатию кнопки Сохранить в трансформированном к структуре другой БД виде этот протокол записывается в Исходящие. С заданной периодичностью Исходящие дублируются на другие сервера. Т.е. иммитируется ситуация, как будто пользователь подключился к удаленному серверу, в другой системе открыл нужную форму и повторил свой ввод, только в другую структуру. Потом в третьей системе открыл и т.д. Никакого извлечения данных, их трансформации не выполняется.

Звучит хорошо. Но представьте себе: пользователь в Москве создаёт, например, заказ:
1 трактор "Кировец", 300 л.с., усиленная подвеска, по 100000$
2 трактора "Беларусь", водяное охлаждение, по 5000$
1 трактор "Беларусь", экскаваторный ковш, бульдозерный нож, по 7000$
1 грузовик "MAN", седельный тягач, по 150000$

В основную БД под Oracle, в Москве, где стоят грузовики "MAN", он записывается, например, как множество связанных записей табличек "документы", "контрагенты", "количества_товаров", "товар_трактор", "товар_грузовик", транзакцией на PL/SQL.

А для остальных создаётся и отправляется, например, XML-файл.

В Костроме, где стоят трактора "Кировец", БД под MS SQL. В ней есть "документы", "контрагенты", "количества_товаров", но "товары" реализованы в виде EAV, "наименования товаров" и "свойства товаров".

В Орле, где стоят трактора "Беларусь" - таблица MS Excel. В ней каждый заказ - несколько строчек в таблице Excel, а все свойства требуемого товара из каждого "количества_товаров" записываются в одной ячейке, в нарушение 1 НФ :) .

А в Санкт-Петербурге, где сидит топ-менеджмент, вообще что-то объектно-ориентированное.

В каждом месте XML-файл должен быть преобразован (Transformation) в последовательность действий по изменению данных, причём, в зависимости от СУБД, в разную. Которая должна быть проведена (Loading). А само построене XML-файла в дополнение к транзакции на PL/SQL, наверное, уже после того, как она зафиксировалась, не Extraction ли?

А зачем? Представьте - стоит везде, например, PostgreSQL и PGCluster, multi-master replication. В одной базе добавил заказ - в другие реплицировалось. И самим ничего (ну почти :) ) писать и отлаживать не надо.

Согласен, для СУБД с поддержкой SQL это замечательный подход. Особенно если СУБД - та же, и структура БД аналогична.
А теперь представьте, что то же самое нужно сделать для FoxPro. Или для MS Excel. И что в удалённой БД таблица IDOCENTRY называется IDO_Centers, а ID - IDO_Centers_Id, причём он не строчный, а численный, и берётся из счётчика. Ведь в условии задачи - не порядок, а зоопарк.

А если "друзей" десяток, и они потихоньку изменяются, из-за чего время от времени "отъезжают"?
Согласен, самодельные сообщения - это решение. Но единообразие и репликация средствами СУБД мне нравится куда больше - это дешевле :) .