Можно ли вложить представления базы данных?

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

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

можно ли вложить представления в этом случае?

меняет ли это, если внутреннее представление содержит еще одно важное представление, содержащее соответствующие цены (т. е. вы" всегда " должны использовать это представление, когда определение цен)?

9
oracle plsql sql views

10 ответов

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

Это означает, что лучший вариант-попробовать вложенные представления. Посмотрите, получаете ли вы разумные планы запросов из отчетов. Если это вызывает проблемы, вам, возможно, придется переосмыслить стратегия.

6

Я просто отвечу с точки зрения лучших практик:

есть только несколько раз я останавливался о мнения о мнения.

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

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

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

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

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

5

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

3

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

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

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

2

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

1

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

1

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

"выберите общая / сумма(столбец col1, столбец col2), сумма(столбец col1, столбец col2) * 2, столбец col1 / сумма(столбец col1, столбец col2) ..."

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

0

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

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

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

0

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

Я видел систему, которая имела представление с 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 был 3-табличным представлением, точные детали неизвестны, но форма:

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 были либо последовательными, либо целочисленными внешними ключами ссылка на серийный ключ.

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

0

на самом деле не хочу увязать во всей вложенной вещи представления

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

выберите num FROM (выберите 1 Как num ОТ DUAL ВЕСЬ СОЮЗ Выберите 2 как num ОТ DUAL СОЮЗ ВСЕ Выберите 3 как num Из DUAL) base_view

минус

выберите 2 как num ОТ DUAL

0