коллеги нужен инструмент для получения данных из MS SQL, FireBird, Progress OpenEdge

zedis
Дата: 11.07.2014 15:58:04
Коллеги прошу о помощи направьте на путь истинный

Задача следующая Есть несколько компаний у них каждой своя ERP система под своей базой данных
1) MS SQL
2) Progress OpenEdge
3) FireBird
4) Oracle

Из этих баз данных в режиме реального времени надо получать карточки товара с характеристиками с остатками и ценами которые разнесены у разных компаний по разным таблицам, нужен универсальный инструмент, Фреймворк, или что то другое который через уровень абстракции баз данных (без необходимости знания каждого из SQL синтаксиса и особенностей сервера) сделать линковку(соотношение) полей таблиц у компаний с полями в нашей базе данных(MS SQL или Oracle). Пример:

1) Компания MS SQL
id->id (в моей базе данных)
product_name-> name(в моей базе данных)
product_weight -> weight(в моей базе данных)
product_power -> power(в моей базе данных)
attribute4-> height(в моей базе данных)

2) Компания MS SQL
item_id->id (в моей базе данных)
item-> name(в моей базе данных)
item_w -> weight(в моей базе данных)
item_p -> power(в моей базе данных)
item_a4-> height(в моей базе данных)

И.Т.Д.

поля могут добавляться и меняться, все это нужно для перекачки данных в нашу базу данных по событию(по запуску) и далее выполнение одного SELECT ко всем базам данных в режиме реального времени только для получения остатков на складах.
Прошу если есть уже с интерфейсом(настраиваем и идет перекачка) что то подобное то отлично если это фреймворк с абстракцией данных то найдем программера который на данном фреймворке напишет эту передачу в режиме реального времени. Но нужно чтоб работала со всеми из перечисленных серверов.


Заранее благодарен за направление и ответы...
Злой Бобр
Дата: 11.07.2014 16:19:18
zedis,

Ну хотеть не вредно.
На самом деле вопрос даже не в отличии конструкции языка, а в структуре БД. У каждого она своя, со своими тараканами. Зачем вам изобретать очередной велосипед - пойдите по пути экспорта-импорта данных из файла. Тот же xml прекрасно справляется даже с весьма большими объемами. Темболее у многих ERP присутствует механизм экспорта данных. Остается только согласовать формат в xml и дело сделано.

P.S.
Если это сторонние конторы то вас никто в БД непустит.
АнатоЛой
Дата: 11.07.2014 16:39:26
zedis, смотри инструменты класса Data Integration. Вплоть до IBM ESB или MS BizTalk.
Pentaho Data Integration был неплох...
SGM
Дата: 12.07.2014 13:13:43
zedis,

Pentaho. компонента Kettle. Делали мы подобные вещи.
обращайтесь ))
Garya
Дата: 12.07.2014 16:06:21
Вариант 1.
Любой из уже задействованных серверов СУБД используется как место концентрации и унификации данных. Для чего настраиваются соединения (Linked Server) с иными серверами, и на этом сервере либо регулярно отрабатывает Task, который сливает данные со всех остальных серверов в некую единую унифицированную структуру, либо используется механизм распределяемых запросов (когда при обращении к View данного сервера View в свою очередь формирует запросы ко множеству иных серверов. Второй способ позволяет всегда быть уверенным в актуальности данных, но результат может получаться не только не очень оперативно, но и с очень большими задержками. Первый способ позволяет разделить по фазам сбор информации с нескольких серверов в некоторой промежуточной унифицированной структуре данных и вернуть итог запрашиваемой информации уже без обращения ко всем-всем-всем серверам. Однако, в этом случае актуальность информации может вызывать больше сомнений.

Вариант 2.
Используется сервер публикации данных и стандартные механизмы подписки, например, входящие в состав MS SQL. Преобразования к единому унифицированному формату могут происходить в процессе сбора данных на сервере публикации данных.

Вариант 3.
В качестве промежуточного места хранения данных в унифицированном формате выступает настольная СУБД (например, MS Access), либо даже таблиця MS Excel. Регулярно запускается скрипт, который задействует либо MS Query, либо ядро настольной СУБД (Jet), и в соответствующие таблицы перекачивается информация изо всех серверов. Для получения итоговых отчетов опять же задействуется либо ядро настольной СУБД, либо MS Query.

Вариант 4.
Задействуется EDI, например MS Biztalk. Это, ПМСМ, и самый грамотный, и самы "навороченный" вариант, который позволяет задействовать не только унифицированные промежуточные структуры хранения данных, но и унифицированные механизмы преобразования данных, встраивания дополнительных видов их обработки (возможно, с участием человека), отслеживания версий их структур и т.д. и т.п.