Предостережения об использовании конвейерных табличных функций в Oracle для реализации функциональности параметризованного представления?

Question

Мы приняли решение наложить несколько «параметризованных представлений» на некоторые обычные представления в Oracle, чтобы должным образом поощрять использование правильных предикатов, которые всегда используются в запросах.

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

Затем мы наложим конвейерные табличные функции на эти представления, чтобыубедитесь, что вызывающие абоненты предоставляют необходимые фильтры, чтобы представления не назывались «на все время и пространство».Я рассмотрел альтернативы, использующие переменные sys_context и userenv и пакета, и, хотя они, по-видимому, являются тем, что пользователи Oracle называют параметризованными представлениями, они просто не способны использовать эти прокладки вокруг представления каждый раз, когда они используются, и их нельзя повторно использоватьself-join.

Я много об этом читал во многих местах, включая StackOverflow:

Табличные функции в ORACLE 11g?(параметризованные представления)

База данных: конвейерные функции

Разрешено ли использование SELECT внутри конвейерной табличной функции PL / SQL?

Это архитектурное решение, направленное на улучшение удобства сопровождения приложения, которое стало разросшимся с большим количеством повторных запросов.Представления могли бы помочь, но я беспокоюсь, что у нас нет способа принудительно использовать предикаты для вызывающих, чтобы они не делали глупостей.

Я достиг большого успеха, используя эту технику в SQLСервер со встроенными табличными функциями, и это действительно помогло сделать систему намного более согласованной и упростить отслеживание зависимостей и последствий предлагаемых изменений, поскольку было: а) меньше кода и б) больше повторного использования и меньше повторений.

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

Пожалуйста, поделитесь своим опытом с конвейерными табличными функциями и что мне нужно посмотреть?Также, если есть лучшая альтернатива, дайте мне знать в своем ответе тоже?

Answer 1

Да, поведение запросов к таблице в конвейерной функции на определенный момент времени отличается от поведения запросов к таблице напрямую или через представление, поэтому это необходимо учитывать.Тем не менее, обычно это не проблема, если конвейерная функция запрашивает редко обновляемую таблицу.Я не могу думать ни о каких проблемах с параллелизмом или синхронизацией.

Моя основная проблема с предоставлением разработчикам конвейерных функций для использования (в отличие от использования представлений) состоит в том, что они (как и некоторые представления) могут легко использоваться неправильно.,Разработчики могут выбрать объединение результатов одной конвейерной функции с другой, что приводит к очень неэффективным запросам, которые не могут использовать преимущества таких вещей, как индексы, заданные предикаты и ограничения таблиц.

Если поддержка является вашей основной проблемой, тогда япредпочли бы представления - они могут помочь уменьшить дублирующийся код, определяя общие преобразования в одном месте и, возможно, общие объединения;однако даже они слишком легко используются неправильно (например, присоединение к представлению, даже если оно присоединяется к другой таблице, которая не требуется исходным запросом).

Производительность и эффективность, вероятно, будут теми вещами, на которые следует обратить внимание,Установите строгий режим проверки для всех SQL в приложении для поиска плохо написанных или противоречивых запросов.