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

Иногда использующие представления запросы невозможно выразить просто как эквивалентные запросы к простым таблицам. Обычно случаи, когда использующий представления запрос возвращает разные результаты из запроса к простой таблице, скрыты и редко возникают. Однако правильные результаты в этих скрытых случаях - это не те результаты, которые получает использующий представления запрос! Если запрос, использующий представления, нельзя легко разложить в эквивалентный простой запрос к таблицам, производительность чаще всего страдает, а скрытые случаи, определяющие поведение, относящееся именно к представлениям, содержат ошибки. Тем не менее, улучшение производительности с практически эквивалентным простым запросом к таблицам не должно приводить даже к небольшим изменениям функциональности, и вам нужно быть очень осторожными, чтобы не внести ошибку. (Чаще всего вы будете исправлять ошибки, а не добавлять новые, но новые ошибки будут более заметны!) Этот случай я проиллюстрирую в разделе Внешние соединения с представлениями .

BHMJVIAHME

Меня часто просят настроить или установить производительность запроса, определяющего представление, не предоставляя мне список всех запросов, использующих данное представление. Также меня просят настроить запросы, использующие представления, не показывая запрос, определяющий представление. Обе эти просьбы невыполнимы. Дело в том, что ни одни определяющий представление запрос, чуть более сложный, чем SELECT <г\исок простых столОцов> FROM <Оана таблицв>, не может прекрасно выполняться во всех возможных запросах, использующих представление. И ни один использующий представление запрос не будет хорошо выполняться, если в запросе, определяющем представление, не используется эффективный путь к необходимым данным.

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

Диаграммное изображение запросов, использующих представления

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

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

2. Создайте диаграмму запроса, использующего представление, считая, что все представления - это всего лишь простые таблицы. У соединения с представлением должна быть стрелка на конце, соответствующем представлению (и вам следует помещать представление на нижний конец связи), только если соединение производится с виртуальным первичным ключом представления. Символически укажите условия фильтрации для представления в запросе, использующем представление, в виде буквы F, не задумываясь пока что о вычислении коэффициента фильтрации. Обведите пунктирной окружностью каждый узел.

3. Разверните диаграмму запроса, использующего представления, созданную на шаге 2, заменив все узлы, соответствующие представлениям, полной диаграммой запроса, определяющего представление, из шага 1. Затем обведите пунктирной линией поддерево запроса, определяющего представление. Любое соединение сверху будет присоединяться к определяющему представление поддереву как его корневой детальный узел. Соединения, отходящие от представления вниз, могут начинаться от любого узла представления, в зависимости от того, какая из таблиц запроса, определяющего представление, содержит внешний ключ (в определяющем представление списке SELECT) соединения. Любое условие фильтрации для представления становится фильтрующим условием соответствующего узла запроса, определяющего представление, в зависимости от того, на столбец какого узла действует зто условие. Найдите фактический коэффициент фильтрации для всех подобных условий обычным способом (дополняя символ F на начальной диаграмме запроса). Если необходимо, комбинируйте коэффициенты фильтрации из определяющих представление и использующих представление запросов, если эти запросы накладывают различные фильтры на одни и те же узлы.

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

Возьмем два определения представлений: CREATE VIEW Sh1pment V AS

SELECT A.Aclclress ID Shipment Address ID. A.Street Addr Linel

Sh1pment Street Address L1nel. A.Street Addr Line2

Shipment Street Address Line2. A.C1ty Name Sh1pment City Name.

A.State Abbrev1at1on Shipment State. A.ZIP Code Shipment ZIP.

S.Shipment Date. S.ShipmentJD FROM Shipments S. Addresses A WHERE S.Address lD = A.Address ID

CREATE VIEW Recent Order V AS

SELECT O.Order ID. O.OrderDate. O.Customer ID.

C.Phone Nuniber Customer Main Phone, С.F1 rst Naine Custonier First Natne. C.Last Naine Customer Last Name.

C.Aclclress ID Customer Address ID. ОТ.Text Order Status FROM Orders 0. Customers C, Codejranslations ОТ WHERE 0.Customer ID = C.Customer ID

AND O.StatusJode = ОТ.Code

AND DT.CodeJype = ORDER STATUS

AND D.DrderJate > SYSDATE - 366

Шаг 1 требует создания диаграмм для обоих определяющих представления запросов, как показмю на рис. 7.33. Для создания этих диаграмм мы воспользовались методом, описанным в главе 5, и использовали ту же статистику для коэффициентов фильтрации и соединения, что и для соответствующего примера, показанного на рис. 5.5.

Запрос, определяющий Запрос, определяющий представление, представление,

Shipment V Order V

Рис. 7.33. Диаграммы запросов для определяющих представления запросов

Вот как выглядит запрос, использующий представление:

SELECT OV.Customer Main Phone. С.Honorific. OV.Customer First Nanie. OV.CustomerJast Name. C.Suffix. OV.CustoiTier AddressJD. SV.Shipment Address ID, SV.Shipment Street AddressjTnel. SV.Shipment Street Address Line2. SV.Shipment City Name. SV.Shipment State. SV.ShipmentJip. DD.Deferred Shipment Date. OD.ItemJount. ODT.Text. P.Product Description. SV.Shipment Date FROM Recent Order V DV. Order Details DD, Products P. Shipment V SV.

Codejranslations ODT. Customers С WHERE UPPER(OV.CustomerJast Name) LIKE :last nameH AND UPPER(OV.Customer First Name) LIKE :first nameЦЖ AND OD.Order ID = DV.Order ID AND OV.Customer ID = C.Customer ID AND DD. Product JD = P. ProductJD(+) AND OD.Shipment ID = SV.Shipment ID(+) AND DD.StatusJode = ODT.Code AND ODT.CodeJype = ORDER DETAIL STATUS ORDER BY OV.CustomerJD. DV.Order ID Desc. SV.ShipmentJD, OD.Order Detail ID

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

Заменим все узлы представлений на рис. 7.34 диаграммами запросов, определяющих представления, с рис. 7.33. А скелеты этих запросов обведем пунктирной кривой, чтобы обозначить границы представлений. Присоединим скелеты определяющих представления запросов к оставшейся части полной диаграммы запроса к подходящим узлам, в зависимости от того, какая таблица из определения представления содержит ключ соединения. Обычно любые соединения с представлением сверху связаны с корневой детальной таблицей определяющего представле-