Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
view на wiew
Guest
У меня в БД есть представления, которые строятся на других представлениях.
Вопрос в том, насколько это правильно с точки зрения Tuning SQL?
7 окт 11, 16:23    [11403538]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
zsgz
Guest
Интересный вопрос, а насколько вообще оправданно делать view на view?

Меня вот, например, жутко бесит, когда вижу view на view, в каждом куча соединений, подзапросы, да еще и обращения к одним и тем же таблицам, сиди отлаживай производительность...
8 окт 11, 20:42    [11407567]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
view на wiew
У меня в БД есть представления, которые строятся на других представлениях.
Вопрос в том, насколько это правильно с точки зрения Tuning SQL?
вопрос, собственно, ни о чем.
это может быть и правильно, и неправильно.
Как и любой запрос в SQL.

У меня есть целая система, которая работает 6 лет, в ней сотня-другая одновременно работающих юзеров, и там вообще нет обращений напрямую к таблицам - на каждую таблицу есть вьюха с ограничением по контексту. А другие вьюхи (куда ж без них) смотрят только на эти. И всё вполне шустро шевелится в нормальном OLTP-режиме.
8 окт 11, 21:05    [11407639]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
есть еще документооборот
построенный на аналогичных принципах и с приличным количеством юзеров
эксплуатация этой системы тоже показала, что вьюхи сами по себе торможения не оказывают
8 окт 11, 21:19    [11407671]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
в своё время создали вьюху, смотревшую сразу на несколько БД
вот тут для производительности ничего хорошего не вышло

(любой смайл)
8 окт 11, 21:28    [11407692]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
zsgz
Guest
Вопрос, когда не стоит делать view на view?

Имхо, если создана прослойка из вьюх с обращениями из примерно 1 таблиц, то view на view это норм, хотя и не всегда приятно.
А если эти вьюшки обращаются к одним и тем же таблицам, то это уже ошибка.
8 окт 11, 21:33    [11407704]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
-2-
Member

Откуда:
Сообщений: 15330
zsgz
А если эти вьюшки обращаются к одним и тем же таблицам, то это уже ошибка.
andreymx
вопрос ответ, собственно, ни о чем.
8 окт 11, 21:43    [11407721]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
zsgz
Guest
-2-
ответ, собственно, ни о чем.

Ага, а потом надо добавить какое-нибудь правое соединение и сиди, лови ошибки из внутренней view, которое неизвестно где используется.
8 окт 11, 21:56    [11407746]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
zsgz
Вопрос, когда не стоит делать view на view?

Имхо, если создана прослойка из вьюх с обращениями из примерно 1 таблиц, то view на view это норм, хотя и не всегда приятно.
А если эти вьюшки обращаются к одним и тем же таблицам, то это уже ошибка.
ты никогда не обращался в запросе к одной и той же таблице несколько раз?
8 окт 11, 23:17    [11407942]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
-2-
zsgz
А если эти вьюшки обращаются к одним и тем же таблицам, то это уже ошибка.
andreymx
вопрос ответ, собственно, ни о чем.
вот бы и ответил о том
8 окт 11, 23:18    [11407943]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
zsgz
Guest
andreymx
ты никогда не обращался в запросе к одной и той же таблице несколько раз?

Так речь-то идёт не об одном запросе, а о двух разных в 2 вьюшках, каждая используется ес-но в своём наборе задач, что и полагается для view.
А проблемы кроме производительности, я написал, добавляем левое соединение, а иногда, даже простой фильтр, или еще что-нибудь по таким таблицам и отгребаем. В одном же представлении, обращение к таблице можно часто оптимизировать, что не скажешь о 2-х вью.
8 окт 11, 23:26    [11407966]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
да, есть у такие нас основные справочные вьюхи, где выведены не все поля. Так сложилось исторически - поля добавлялись в исходные таблицы, а уже во вьюхи не всегда - а хрен его знает, где эта вьюха уже используется последние 6 или 7 лет, сколько и каких полей в этих запросах и с какими алиасами.
Ну и приходится таблицы повторно использовать.
8 окт 11, 23:33    [11407993]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
zsgz
Guest
А еще проблема, каждая из вьюшек со временем разрастается и уже пересекаются многими таблицами потом. И вьюшки на вьюшках поначалу работали нормально, а потом вдруг начинают тормозить ни стого ни с сего. Заходишь, а там мать твою за ногу, что во внутренней вьюшке!
8 окт 11, 23:45    [11408035]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
hoarfrost
Member

Откуда: Волгоград
Сообщений: 438
view на wiew
У меня в БД есть представления, которые строятся на других представлениях.
Вопрос в том, насколько это правильно с точки зрения Tuning SQL?

Если я не ошибаюсь, то именно так построен весь словарь данных Oracle Database. :)
10 окт 11, 10:06    [11410584]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
Примерчик приведи
А так же расшифруй, что ты понимаешь под "словарем"
10 окт 11, 10:12    [11410621]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63972
Блог
view на wiew
Вопрос в том, насколько это правильно с точки зрения Tuning SQL?

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

zsgz
Интересный вопрос, а насколько вообще оправданно делать view на view?

С точки зрения красиво спроектированного кода без дублирования скорее оправданно. Только, боюсь, спроектировать вьюхи и их взаимоотношения настолько разумно, чтобы они выдержали многолетние доработки - трудно, если не невозможно.
10 окт 11, 10:29    [11410735]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 54383
softwarer
zsgz
Интересный вопрос, а насколько вообще оправданно делать view на view?

С точки зрения красиво спроектированного кода без дублирования скорее оправданно. Только, боюсь, спроектировать вьюхи и их взаимоотношения настолько разумно, чтобы они выдержали многолетние доработки - трудно, если не невозможно.
вот и щаз смотрю тут на вьюху...
добавишь внтурь неё хинт /*+ ordered */ - летает вьюха!
но вот не полетит ли нафиг всё остальное?
:)
10 окт 11, 10:54    [11410917]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63972
Блог
andreymx, я так думаю, что если принимать структуру "вьюха на вьюху", то надо чётко отделять "промежуточные" от "конечных". Это что-то вроде наследования классов, только ещё сильнее: если вьюха конечная, её можно довольно свободно править по месту, а вот в "промежуточные" подозрительные вещи совать только ооочень крепко подумав. То есть в таком случае может лучше изготовить конечную вида select /*+ ordered */ * from MyView.
10 окт 11, 11:05    [11411016]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
-2-
Member

Откуда:
Сообщений: 15330
select level, count(*) 
from dba_dependencies t
start with (owner, type) = (('SYS','VIEW'))
connect by (prior owner, prior name, prior type) = ((referenced_owner, referenced_name, referenced_type)) and (owner, type) = (('SYS','VIEW'))
group by level
order by 1
;

LEVEL                  COUNT(*)               
---------------------- ---------------------- 
1                      14078                  
2                      11257                  
3                      10104                  
4                      9636                   
5                      8952                   
6                      6546                   
7                      5351                   
8                      3414                   
9                      2378                   
10                     1260                   
11                     300                    

softwarer
многолетние доработки
независимо от разумности проектировщика и вариантов мутации бизнес-сущностей и связей - анализировать явные зависимости обычно проще, чем дублирование кода в разных местах разными программистами.
10 окт 11, 11:13    [11411066]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63972
Блог
-2-
независимо от разумности проектировщика и вариантов мутации бизнес-сущностей и связей - анализировать явные зависимости обычно проще, чем дублирование кода в разных местах разными программистами.

Зависимости в обоих случаях явные, только в одном случае "звезда", в другом - "снежинка". В данном случае вопрос, что дороже - "внесение изменения во все места, где оно нужно" или "срабатывание изменений в тех местах, где оно не нужно".
10 окт 11, 11:21    [11411134]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
hoarfrost
Member

Откуда: Волгоград
Сообщений: 438
Вячеслав Любомудров
Примерчик приведи


Например вот такой:
SQL> SELECT TO_CHAR(DBMS_METADATA.GET_DDL('VIEW', 'ALL_STREAMS_UNSUPPORTED', 'SYS')) FROM DUAL;

TO_CHAR(DBMS_METADATA.GET_DDL('VIEW','ALL_STREAMS_UNSUPPORTED','SYS'))
-----------------------------------------------------------------------------------------------------------------------------

  CREATE OR REPLACE FORCE VIEW "SYS"."ALL_STREAMS_UNSUPPORTED" ("OWNER", "TABLE_NAME", "REASON", "AUTO_FILTERED") AS
  select s."OWNER",s."TABLE_NAME",s."REASON",s."AUTO_FILTERED" from DBA_STREAMS_UNSUPPORTED s, ALL_OBJECTS a
   where s.owner = a.owner
     and s.table_name = a.object_name
     and a.object_type = 'TABLE'

SQL> SELECT TO_CHAR(DBMS_METADATA.GET_DDL('VIEW', 'DBA_STREAMS_UNSUPPORTED', 'SYS')) FROM DUAL;

TO_CHAR(DBMS_METADATA.GET_DDL('VIEW','DBA_STREAMS_UNSUPPORTED','SYS'))
-----------------------------------------------------------------------------------------------------------------------------

  CREATE OR REPLACE FORCE VIEW "SYS"."DBA_STREAMS_UNSUPPORTED" ("OWNER", "TABLE_NAME", "REASON", "AUTO_FILTERED") AS
  select owner, table_name, reason, auto_filtered
   from (select * from "_DBA_STREAMS_UNSUPPORTED_9_2"
         where compatible = dbms_logrep_util.get_str_compat() union
         select * from "_DBA_STREAMS_UNSUPPORTED_10_1"
         where compatible = dbms_logrep_util.get_str_compat() union
         select * from "_DBA_STREAMS_UNSUPPORTED_10_2"
         where compatible = dbms_logrep_util.get_str_compat())

SQL> SELECT TABLE_NAME FROM DICTIONARY WHERE TABLE_NAME IN('ALL_STREAMS_UNSUPPORTED', 'DBA_STREAMS_UNSUPPORTED');

TABLE_NAME
------------------------------
ALL_STREAMS_UNSUPPORTED
DBA_STREAMS_UNSUPPORTED

SQL>

А так же расшифруй, что ты понимаешь под "словарем"

Имею ввиду Data Dictionary. Т.е. Base Tables и Views.
10 окт 11, 15:32    [11413618]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18484
В общем, да
В последнее время с развитием новых фич понапихали такого рода зависимостей.
11 окт 11, 03:51    [11417170]     Ответить | Цитировать Сообщить модератору
 Re: Оправдано ли делать view на view с точки зрения Tuning SQL?  [new]
ораклоид-свинопас
Guest
Вячеслав Любомудров
В общем, да
В последнее время с развитием новых фич понапихали такого рода зависимостей.
Ленивые долбодятлы есть везде. Oracle не исключение
11 окт 11, 06:31    [11417196]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить