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-трансформацию, она как раз и работает как нужно - возвращает записи для каждой записи из основного потока. Но, как я понимаю, так мог бы работать и лукап.. Или нет?