Это в порядке для вложения представлений базы данных?

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

Я просто отвечу с точки зрения передового опыта:

Лишь несколько раз я бы остановился на использовании представлений на представлениях.

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

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

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

4. Производительность - большая проблема.

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

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

Это все субъективно. Если это имеет смысл, используйте это. Не оптимизируйте код раньше времени.

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

Я встраиваю представления на 3 уровня в Oracle 10g R2. Производительность кажется сопоставимой с операторами select в представлениях, а не с глубиной представления. В частности, предложение "IN", похоже, вызывает много проблем.

Также хорошо отметить, что в процессе построения сложных запросов к базе данных иногда лучше всего подходят вложенные представления - например, если вам нужен какой-либо математический оператор, построенный на двух столбцах, например SUM (Col1, Col2), может быть лучше вложить представления, чтобы сумма представляла собой столбец, вместо того, чтобы делать что-то вроде

«ВЫБРАТЬ Итого / SUM (Col1, Col2), SUM (Col1, Col2) * 2, Col1 / SUM (Col1, Col2) ... "

Однако я не уверен, что понимаю 100% - зачем нужны 2 просмотра? Разве оба пользователя не могут смотреть на одно представление, и дальнейшая обработка может производиться на другом слое выше этого представления?

Наилучшими причинами для использования представления были бы следующие:

1. предотвращение дублирования одного и того же запроса.
2. предотвращение прямого доступа к таблицам другими авторами запросов
3. создание уровня безопасности (аналогично №2.)

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

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

Я действительно видел систему, в которой было представление с 14 явно указанными таблицами, некоторые из которых были связаны с внешними самосоединениями, а некоторые из «таблиц» были сами собой Просмотры. Мне это не очень понравилось, но СУБД с этим справилась на удивление хорошо (учитывая, что это было еще в конце 80-х). Большая часть схемы была сгенерирована машиной с помощью инструмента моделирования данных.

CREATE VIEW IBB_V_Project AS
    SELECT  A.Project_Iref,
            A.Section_Iref,
            B.Section_Eref,
            N.Company_Iref,
            N.Company_Name,
            A.Product_Desc,
            A.Project_Type_Iref,
            D.Project_Type,
            A.Person_Iref,
            F.Full_Name,
            A.Respon_Iref,
            G.Post_Location,
            A.Project_Stat_Iref,
            E.Project_Status,
            A.Source_Iref,
            I.Source,
            A.Sic_Iref,
            L.Sic_Eref,
            A.Op_Activity_Iref,
            M.Op_Activity_Desc,
            A.Involve_Iref,
            K.IBB_Involvement,
            A.Nature_Iref,
            C.Nature_Of_Next_Act,
            A.Internat_Mobile,
            A.Whether_Cop_Case,
            A.Closed_Ind,
            A.Next_Action_Date,
            A.Creation_Date,
            A.Last_Edit_Date,
            A.Last_Editor_Iref,
            H.Logname

    FROM    IBB_Project A,
            IBB_Section B,
            IBB_R_Proj_Type D,
            IBB_R_Project_Stat E,
            IBB_Personnel H,
            OUTER IBB_R_Next_Act C,
            OUTER IBB_Personnel F,
            OUTER (IBB_Post_Respon X, OUTER IBB_V_Post_Resp2 G),
            OUTER IBB_R_Source I,
            OUTER IBB_R_Involvement K,
            OUTER IBB_Sic L,
            OUTER IBB_Op_Act M,
            OUTER IBB_V_Proj_Co2 N

    WHERE   A.Section_Iref      = B.Section_Iref
      AND   A.Project_Type_Iref = D.Project_Type_Iref
      AND   A.Project_Stat_Iref = E.Project_Stat_Iref
      AND   A.Last_Editor_Iref  = H.Person_Iref
      AND   A.Nature_Iref       = C.Nature_Iref
      AND   A.Person_Iref       = F.Person_Iref
      AND   A.Respon_Iref       = X.Respon_Iref
      AND   X.Respon_Iref       = G.Person_Iref
      AND   A.Source_Iref       = I.Source_Iref
      AND   A.Sic_Iref          = L.Sic_Iref
      AND   A.Op_Activity_Iref  = M.Op_Activity_Iref
      AND   A.Project_Iref      = N.Project_Iref
      AND   A.Involve_Iref      = K.Involve_Iref;

Нотация внешнего соединения специфична для Informix (который теперь также поддерживает стандартную нотацию SQL).

Обратите внимание, что IBB_V_Post_Resp2 и IBB_V_Proj_Co2 сами по себе являются представлениями. Фактически, IBB_V_Proj_Co2 был представлением с тремя таблицами, точные детали неизвестны, но о форма:

CREATE VIEW IBB_V_Proj_Co2 AS
    SELECT  A.Project_Iref,
            A.Some_Other_Col col01,
            B.Xxxx_Iref,
            B.Some_Other_Col col02,
            C.Yyyy_Iref,
            C.Some_Other_Col col03
    FROM    IBB_Project A,
            OUTER (IBB_R_Xxxx B, IBB_R_Yyyy C)
    WHERE   A.Xxxx_Iref = B.Xxxx_IrEf
      AND   B.Yyyy_Iref = C.Yyyy_Iref;

Это означает, что представление IBB_V_Project имеет внешнее самосоединение на IBB_Project. Представление IBB_V_Post_Resp2, вероятно, включало 3 таблицы тоже (мои примечания по этому поводу были немного неясными еще в 1993 году, когда я записал эту информацию).

CREATE VIEW IBB_V_Post_Resp2 AS
    SELECT  A.Person_Iref,
            A.Some_Other_Col col01,
            B.Xxxx_Iref,
            B.Some_Other_Col col02,
            C.Yyyy_Iref,
            C.Some_Other_Col col03
    FROM    IBB_Personnel A,
            IBB_R_Xxxx B,
            IBB_R_Yyyy C
    WHERE   A.Xxxx_Iref = B.Xxxx_Iref
      AND   B.Yyyy_Iref = C.Yyyy_Iref;

Столбцы Zzzz_Iref были внешними ключами SERIAL или INTEGER ссылка на ключ SERIAL.

Определение основного представления относится к 14 таблицам с 4 внутренними объединениями и 9 внешние соединения. Когда учитываются перекрестные ссылки, там всего 18 таблиц, с 7 внутренними соединениями и 10 внешними соединениями.

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

подумайте об этом для идеи ... вы пытаетесь присоединиться к таблице, чтобы найти несоответствия ... я бы использовал функцию Oracle 'минус' .... MINUS выбирает элементы из первой таблицы, а затем удаляет строки, которые также возвращаются вторым оператором SELECT.

ВЫБРАТЬ число ОТ (ВЫБЕРИТЕ 1 КАК число ОТ ДВОЙНОЙ СОЮЗ ВСЕ ВЫБЕРИТЕ 2 КАК число ОТ ДВОЙНОЙ СОЮЗ ВСЕ ВЫБЕРИТЕ 3 КАК число FROM DUAL) base_view

MINUS

ВЫБРАТЬ 2 КАК число ИЗ ДВОЙНОЙ