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

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

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

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

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

8
oracle oracle10g sql views

6 ответов

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

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

но имейте в виду следующее:

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

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

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

6

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

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

5

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

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

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

2

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

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

1

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

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

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

0

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

использует мнениями

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

http://www.smart-soft.co.uk/Oracle/oracle-tuning-part4-vw-use.htm

0