Есть ли причина не использовать представления в Oracle?

Question

Я недавно заметил, что никто не использует представления в моей компании (а это большая компания).

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

Моя альтернатива - создать таблицу типов записи типа и заполнять ее каждый раз, когда вызывается SP. Это лучше, чем использовать вид? (я думаю, нет)

PS: база данных Oracle и 10g РЕДАКТИРОВАТЬ: - Да, я спрашивал вокруг, но никто не мог дать мне причину. - и представления, и запросы, которые будут их использовать, являются тяжелыми для объединений.

Answer 1

Эстетикам не место в SQL или кодировании вообще, когда это влияет на производительность.

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

Но учтите следующее:

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

Я рекомендую создать ваши представления и сравнить планы EXPLAIN, чтобы убедиться, что вы, по крайней мере, получаете одинаковую производительность. Мне нужно увидеть ваш код для заполнения ТИПА, прежде чем комментировать подход, но по сути он звучит как производная таблица ...

Возможно, вам было бы полезно использовать материализованные представления, но они общеизвестно ограничены в том, что они поддерживают.

Answer 2

Похоже, что создание некоторых представлений будет полезно в этом случае.

Вы спрашивали вокруг, чтобы узнать, почему никто не использует представления? Это кажется довольно странным и, безусловно, может указывать на то, что вы не очень эффективно используете свой SQL. Без представлений вы склонны использовать одну и ту же логику во многих различных операторах SQL, а не в одном представлении, что усложнит обслуживание.

Answer 3

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

Например, я мог бы написать

CREATE VIEW foo as <SOME COMPLEX QUERY>

потом я смогу написать

CREATE Procedure UseFoo as 
BEGIN
       SELECT 
          somefields
       FROM
          x 
          INNER JOIN foo
         .....

Итак, теперь я создаю объекты, которые необходимо развернуть, поддерживать, контролировать версии и т. Д. *

Или я мог написать либо

CREATE Procedure UseFoo as 
BEGIN
       WITH foo as (<SOME COMPLEX QUERY>)
       SELECT 
          somefields
       FROM
          x 
          INNER JOIN foo
         .....

или

CREATE Procedure UseFoo as 
BEGIN

       SELECT 
          somefields
       FROM
          x 
          INNER JOIN <SOME COMPLEX QUERY> foo
         .....

И теперь мне нужно только развернуть, поддерживать и контролировать версии одного объекта.

Если <SOME COMPLEX QUERY> существует только в одном контексте, поддержание двух отдельных объектов создает ненужную нагрузку. Также после развертывания любые изменения требуют оценки вещей, которые зависят от UseFoo. При двух объектах вам нужно посетить все, что оценивается по UseFoo и Foo

Конечно, с другой стороны, если Foo представляет некоторую общую логику, оценка все равно требуется, но вам нужно только найти и изменить один объект.

Answer 4

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

Из вашего описания я бы просто сделал вид, а не новую таблицу.

Answer 5

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

Использование представлений

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

http://www.smart -soft.co.uk / Oracle / oracle-tuning-part4-оч.сл.-use.htm

Answer 6

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

Но представления также имеют проблемы с производительностью - если ваши пользователи знают, как писать sql, и они понимают таблицы, которые они используют, может быть, лучше позволить им продолжать это делать.

Учтите также, что хранимые процедуры менее подвержены (тем же) проблемам производительности, что и представления.