Наследование вьюшек

Собственно вопрос есть ли в оркал механизм наследования вьюшек?
То есть допустим, есть некая базовая вьюшка

myscheme.v_myview

На ее основе сделал другие вьюшки с добавлением других полей (в каждую свои)
типа

create view myscheme.v_childview1 as 
  select v_myview.*,... from myscheme.v_myview,
                                  myscheme.mytable1...
/

create view myscheme.v_childview2 as 
  select v_myview.*,... from myscheme.v_myview,
                                  myscheme.mytable2...
/

Вопрос. Я изменил базовую вьюшку myscheme.v_myview (добавил поля в нее или удалил)
по идее мне теперь надо переделать все дочерние вьюхи...
Как бы это красиво сделать? Или может есть стандартный механизм (было бы супер)?
То есть понятно, что если бы в списке полей вью можно было просто оставить v_myview.*,
так оракл же их все развернет... или я неправ?

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

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

Кууу

писать для каждого руками свю вьюху тоже не выход

Это как раз выход. Не тысячи же у Вас представлений, использующих таблицу с меняющейся структурой. И не каждый день структура у этой таблицы меняется.

автор

Собственно вопрос есть ли в оркал механизм наследования вьюшек?

Нет, в том виде что вы хотите.

Если вы посмотрите тело вьюхи созданной по принципу :

create view myscheme.v_childview1 as 
  select v_myview.*,... from myscheme.v_myview,
                                  myscheme.mytable1...

Он будет выгладить:

create view myscheme.v_childview1 as 
  select myscheme_v_myview_FIELD1,myscheme_v_myview_FIELD2,myscheme_v_myview_FIELD3 from myscheme.v_myview,
                                  myscheme.mytable1...

Можно написать процедуру: которая бы находила все вьюшки в которых используется ваша (referenced by) и обновлять поля.

suPPLer

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

В том то и дело, что если делать представлений столько сколько нужно, получится довольно много - ноги растут из ситуации:
1. на клиенте есть грид, который тянет данные из вьюшки (к примеру некие документы)
изначально в гриде допустим 20 полей.
2. дальше происходит следующее: каждому заказчику нужны еще какие-то поля из других таблиц, внутри каждого заказчика сотрудникам одного подразделения нужны еще некоторые поля из других таблиц другого подразделения еще другие поля и так вплоть до того, что каждому юзеру нужны какие-то его поля
3. в результате в эту одну вьюху добавляется под сотню таблиц и такое же количество полей,
и в грид тоже - представляете ползать по гриду с сотней полей (есть механизм, скрывающий поля в гриде для каждого пользователя) но он же все равно обращается к той огромной вьюхе и тащит все поля на клиент - просто не отображает
Вот и хотелось бы как-то это все разбить на несколько вьюх, кому что надо, но сделать это более менее гибко и легко конфигурируемо/сопровождаемо

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

Можно написать процедуру: которая бы находила все вьюшки в которых используется ваша (referenced by) и обновлять поля.

Это да, но думал, может есть более простой вариант.

Наследник

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

Я извиняюсь за грубость, но - по пальцам этому каждому юзеру! :) Если у каждого пользователя своё видение того, что ему нужно - выделите общую часть данных, которые нужны всем, затем данные, которые в эту общую часть не попали, но нужны для выполнения функциональных обязанностей должности. Это и будут Ваши основные представления. А из оставшегося можно делать гриды других форм и отчёты, где и использовать, если понадобится, DSQL и вьюхи для часто повторяющихся запросов.

автор

Я извиняюсь за грубость, но - по пальцам этому каждому юзеру! :) Если у каждого пользователя своё видение того, что ему нужно - выделите общую часть данных...

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

Наследник

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

Сталкивался с подобной ситуацией, реализовал ее следующим образом:
на клиенте делал запрос вида:

select 
  t1.Fiel,
  t2.Fiel,
  t3.Fiel
from 
  table1 t1,
  table2 t2,
  table3 t3 
where t1.id=t2.id
      and t2.id=t3.id

Дальше разбивал его на макросы ( ODAC) до вида

select 
  &T1_F         -- макрос скрывает текст: "t1.Fiel,"
  &T2_F         -- макрос скрывает текст: "t2.Fiel,"
  &T3_F         -- макрос скрывает текст: "t3.Fiel"
from 
  &T1_T         --макрос скрывает текст: "table1 t1,"
  &T2_T         --макрос скрывает текст: "table2 t2,"
  &T3_T         --макрос скрывает текст: "table3 t3 "
where &T1_T2_W  --макрос скрывает текст: "t1.id=t2.id"
      &T2_T3_W  --макрос скрывает текст: "and t2.id=t3.id"

На клиенте позволяем пользователям убирать и добавлять колонки. Перед получением данных делаем проверку - убрана ли колонка или нет и в зависимости от этого включаем и выключаем макросы.

if t1_Fiel.Visible=True then 
DSet.MacroByName('T1_F').Active    :=  True; 
DSet.MacroByName('T1_T').Active    :=  True; 
DSet.MacroByName('T1_T2_W').Active    :=  True; 
else
DSet.MacroByName('T1_F').Active    :=  False; 
DSet.MacroByName('T1_T').Active    :=  False; 
DSet.MacroByName('T1_T2_W').Active    :=  False; 
end;

Если это 2х звенка ..

Наследник

Или может есть стандартный механизм (было бы супер)?

Увы, был. STFF Вопрос про view