1) Как таковой цели разгрузить БД не стоит. Надо понимать и помнить, что в общем случае источниками данными могут быть разные БД, файлы, веб-сервисы и еще что-то. А теперь представьте, что тоже самое вы захотите сделать на условном PLSQL. Сколько потребуется ресурсов, чтобы настроить все эти гетерогенные сервисы? Informatica этот вопрос снимает. Даже гетерогенный сервис Oracle-MSSQL достаточно геморройное занятие.

2) Запросы к БД в любом случае будут выполняться на сервере БД Как-то может быть иначе? Просто, если вы напишете запрос ручками в SQL Override, то выполнится он, не напишете - выполнится тот, который напишет за вас информатика

3) В общем верно. Но такие вещи можно делать через SQ+Joiner, но не значит, что можно=всегда нужно

4) Есть такое мнение. Но по моему не очень большому опыту не было ситуации, когда отрисовал маппинг без Sorter-ов и работало долго, а добавил Sorter - все полетело... Чаще всего больше времени требуется не вычитывание из БД, чем на сами трансформации. Но, если данных миллионы, вероятно, профит должен быть

5) Вопрос интересный.. Насколько я понимаю, так быть не должно. Но вот что будет происходить, если на вход в Joiner приходит два отсортированных потока по разным полям (к примеру, зачем так делать - не знаю), то что будет на выходе (если это Normal Join) - это бы проверить. Предполагаю, что сортировка будет сохраняться у потока, где проставлена галочка Master на портах (ведь она активна и для Normal Join тоже)

А для Lookup - а он почему должен ломать сортировку? Это ведь по сути левое соединение

По поводу обсуждения - мне было бы очень интересно какие-то вопросы обсуждать.

авторНо разгрузку на базу всё равно наверное дают, благодаря тому что делят большой тяжёлый запрос на более мелкие лёгкие части. Верно ?
Ну на этот вопрос нет однозначного ответа. Информатика выполнит только те запросы, которые вы отрисуете. Например, есть у нас один большой запрос с тяжелыми таблицами, но структура такова, что есть партиция, которую вы выбираете, либо супер селективный индекс и вы передаете селективный параметр в фильтра. План запроса построен хорошо - сначала читается маленькая таблица, а в к ней джойнится гиганская без необходимости ее фулскана. Отрисовали в тупую на информатику:
- вычитываете мелкую таблицу
- вычитываете большую таблицу
- где-то там после после наложения фильтров через трансформацию Filter фильтруете потоки
- и только потом джойните между собой два потока

Вопрос - какая гарантия, что работать это будет лучше и быстрее запроса и меньше грузить будет БД? :) С большой таблицы сначала вычитываться 100500 строк, а только потом будет делаться джоин. И делать это будет не оракловый оптимизатор (если мы об оракле), у которого есть статистика, используя которую он строит план запроса, а просто некий код, который возьмет считанные и положенные в кэш-файлы.

авторSQ+Joiner - это User Defined Join в SQ. Теперь у меня понимание лучше сложилось. Кроме условий связи есть ещё условия фильтрации, но их наверное в Source Filter в SQ, отдельно надо писать.
Нет, я имел ввиду SQ + отдельный компонент Joiner. Условия фильтрации можно задавать как вам угодно - прямой запрос в SQL Override, User Defined Join в SQ, трансформация Filter. Выбирайте любой, какой подходит в каждой ситуации.
Вообще, никто не обязывает вас в одном SQ использовать запрос только к одной таблице. Вы можете сделать как в БД - записать туда гигантский запрос с множеством таблиц, и он выполнится точно так же в БД (с поправкой на параметры сессии и NLS, которые могут отличаться), как вы делали бы это ручками.

авторИнформатика заставляет явно select-ить в Override поля для связи (на вкладке Condition). Так и не понял зачем. Если строит запрос и отправляет на сервер, почему не достаточно, что условия связи и так уже указаны.
Не до конца понятно, о чем вы. Но селектить нужно все, что вы хотите достать из БД. В данном контексте поле для связи ничем не отличается от поля, которое в select листе. Каждый запрос выполняется отдельно, результат складывается в кэш, а то только после этого данные вяжутся. Как же два несвязанных массива свяжутся, если в них нет для этого ключей? Это в БД они рядышком лежат, в для информатики это просто два неких массива, не более того..

мнениеЧто делая так - я отправляю сложный запрос на базу, а это для неё очень большая нагрузка, если таких маппингов одновременно будет несколько.
Идея средств ETL разработки, чтобы вычитать "лёгкими" селектами (лёгкость высчитывается опытным путём) необходимые данные в информатику и уже на сервере информатики производить операции с этими данными.
А sq, по возможности нужно делать максимально простым. Вычитать строки, а все преобразования - в информатике - в этом её и суть.
Хороший маппинг работает быстро, не нагружает базу, по возможности максимально лаконичный.

Вполне разумно. Но на практике оно бывает по-разному. Оно как бы как - если данные забираются с прода какой-нибудь нагруженной АБИС, то грузить ее на надо. Но чаще всего есть какой-нибудь stand-by с онлайн-репликацией, и его уже можно подгрузить. А порой нужно, чтобы процесс загрузки работал быстро, бизнес ждет данные. А отрисовать его тоже нужно было еще вчера, а руководству уже доложено, что он уже месяц как работает.. А источник - большой скрипт, его надо разобрать, разделить на SQ, 10 штук их отрисовать, день потратить. А скрипт работает быстро, секунды. Разработчик репку почесал, весь скрипт в один SQ записал, порты забил, отрисовал все до таргета, запустил - пару секунд и данные в таргете. Успех :)

Значит ли это, что лукап в данном случае будет работать как подзапрос в БД? То есть, что таблица или запрос не будет вычитывать все данные полностью, а передавать в качестве параметров поля из основного потока для возврата каждой записи?

Почему спрашиваю. Недавно была сложность, переписывал большой скрипт на IPC. Все бы ничего, но там было 100500 подзапросов, в каждый из которых передавались поля в where. Таблицы, из которых подзапросы брали данные, были гигантские, однако имели очень селективные индексы и при передаче извне условий фильтрации работали достаточно шустро. Переписал все это на IPC и получилось, что сначала все вычитывается, потом только вяжется с основным потоком. Решил через SQL-трансформацию, она как раз и работает как нужно - возвращает записи для каждой записи из основного потока. Но, как я понимаю, так мог бы работать и лукап.. Или нет?

Хороший текст у вас. Абсолютно те же наблюдения и мысли у меня появлялись. Для себя сделал пару выводов:
- если баз не одна, а 100500, то как некое централизованное ETL-средство - норм. Тем более в банках, где без нее приходилось бы кидать дблинки, открывать порты всем подряд. Безопасности это всегда не нравится
- если источники разнородные. Быстро подтянуть данные из разных СУБД, веб-сервиса, еще откуда-то и слить их в один таргет достаточно сложно будет иными средствами. Другое дело, что таких задач 1 на 1000
- Enterprise любит готовые решения, чтобы была поддержка и гарантии, что самописный питон завтра не свалится, а писавший его народ не разбежится

Я про то, что, чтобы забрать данные из двух разных БД, достаточно дать доступы серверу информатики к этим БД, а не между этим БД. В этом ключе


Бесспорно. Но я о том, что такое решение уже должно быть. А информатика его как бы предоставляет заранее. Если деньги ляшку не жгут, то и идут и покупают информатику, наслушавшись ее продажников


И с этим согласен. Речь о том, что для руководства условного ДИТ условного банка может быть выгоднее(проще, безопаснее в плане поддержки) купить одну большую систему вместе с поддержкой от условного ДИС, чем привести 100 мелких компаний со своей etl-разработкой на условном питоне

И вообще - мой пост не про преимущества информатики над теми решениями, что вы описывали. Абсолютно с вами согласен. Речь о том, какие причины нашел для себя, которые могут служить причиной покупки и внедрения информатики отдельно взятой конторой

Доброго дня!
Столкнулся с непонятной мне вещью.. Пытаюсь внести правки в маппинг - нужно добавить поля в SQ. Перетаскиваю поля из Source в SQ, поле добавляется в SQ, но при этом линк не отрисовывается. Думал, может графический глюк...перезашел в дизайнер, переподключился к репозиторию - ничего. Попробовал новый порт добавить руками в SQ, а потом указать ему поле в источнике - не пашет. Что за прикол?

upd. Проверил возможность добавления линков дальше. Пытаюсь руками созданный порт SQ добавить в Joiner - та же история, порт добавляется, линк не рисуется

upd2. Все просто.. Не был включен Link Column в Layout :(

Господа, ищу помощи.

Имею маппинг, в котором собирается некий поток данных. Он пропускается через Router и по условию разделяется на два потока - один отправляет данные на инсерт, другой на апдейт. Апдейт выглядит как: ...Router->Update Strategy->Target.

По настройкам:
- в Update Strategy установлено 1(DD_UPDATE тоже пробовал)
- на таргете включена галочка "Update as Update"
- коннект к таргету под пользователем-владельцем таблицы, то есть права на апдейт в БД имеются

В логах вижу следующее:




По непонятной мне причине информатика хочет инсертить эту запись, а не апдейтить.. Куда смотреть?
Спасибо