Комментарии 2
Вообще, обычно хорошей практикой считается не использовать в коннекторах ETL джобов
сложных SQL запросов. Это уменьшает читаемость дизайна процесса и перекладывает решение вопросов производительности на плечи СУБД. Тогда бы и не возникало необходимости убирать whitespaces из запроса, так как вы бы использовали lookup-датасеты или таблицы вместо списка кодов в запросе. Что также было бы неплохим решением, так как, допущу, этот список может использоваться во многих процессах переливки.
сложных SQL запросов. Это уменьшает читаемость дизайна процесса и перекладывает решение вопросов производительности на плечи СУБД. Тогда бы и не возникало необходимости убирать whitespaces из запроса, так как вы бы использовали lookup-датасеты или таблицы вместо списка кодов в запросе. Что также было бы неплохим решением, так как, допущу, этот список может использоваться во многих процессах переливки.
Geckelberryfinn, спасибо за комментарий по делу.
Со своей стороны объясним, чем был обусловлен подход, примененный на этом проекте:
— использованием реинжиниринга текущего функционала без привлечения экспертов со стороны системы-источника;
— сложной логикой преобразования данных, реализованной на PL/SQL, что и привело к тому, что пришлось писать сложные SQL-запросы (нереализуемые трансформациями Informatica).
Причем это относится ко всему проекту, а не только к описываемому кейсу.
Со своей стороны объясним, чем был обусловлен подход, примененный на этом проекте:
— использованием реинжиниринга текущего функционала без привлечения экспертов со стороны системы-источника;
— сложной логикой преобразования данных, реализованной на PL/SQL, что и привело к тому, что пришлось писать сложные SQL-запросы (нереализуемые трансформациями Informatica).
Причем это относится ко всему проекту, а не только к описываемому кейсу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лайф-хаки для разработчиков: эффективное использование SQ (Source Qualifier) в Informatica Power Center