Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 121

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 115 116 117 118 119 120 < 121 > 122 123 124 125 126 127 .. 161 >> Следующая


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

Внешние соединения с представлениями

Возвращаясь к предыдущему примеру, рассмотрим, что же означает наличие внешнего соединения с представлением ShipmentJ/, которое само по себе является внутренним соединением между таблицами Shipments и Addresses. Так как база данных должна считать, что существует реальная таблица с точно теми строками, которые найдет представление, соединение обнаруживает внутреннее соединение для значений Shipment_ID, которые присутствуют в Shipments и указывают на поставки, поле Address_ID для которых успешно соединяется с таблицей Addresses. Если база данных не может провести успешное соединение одновременно и с Shi pments, и с Addresses, то соединение с представлением становится полностью внешним (с обеими таблицами), даже если первое соединение с Shipments могло пройти успешно. При поиске плана со вложенными циклами база данных не может знать, будет ли для внешнего соединения найден внутренний случай, пока не проведет успешное соединение с обеими таблицами в запросе, определяющем представление.
246

7. Диаграммное изображение и настройка сложных SQL-запросов

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

ВНИМАНИЕ --------------------------------------------------------------------------

В качестве основного правила для улучшения производительности избегайте внешних соединений с любыми представлениями, более сложными, чем SELECT <Список_простых_столбцов> FROM <Оцна_ табпица>.

Схожие проблемы возникают для всех типов соединений с представлениями, в которых в определяющем представление запросе присутствуют UNION или GROUP BY. Однако соединения, исходящие от подобных представлений, когда в них есть таблица, которую можно выбрать ведущей таблицей запроса, обычно работают прекрасно.

Снова рассмотрим использующий представление запрос из предыдущего подраздела. Если вы поместите определяющий представление запрос для Shipment V в запрос, использующий представления, чтобы разрешить проблему производительности с внешним соединением, то, вероятно, получите такой результат:

SELECT OV.Customer_Main Phone. С.Honorific. OV.Customer First Name.

0V. CustomerJast JJame. С.Suffix, OV.Customer_Address_ID.

A.Address ID Shi pment_Address_ID.

A.Street_Addr_Linel Shipment_Street_Address_Linel.

A.Street_Addr Li ne2 Shi pment_Street_Address Ji ne2.

A.CityJIame Shipment_City_Name. A.State__Abbreviation Shipment_State.

A.ZIP_Code Shipment_ZIP. OD. DeferredJ>hipJ)ate. DD.Item_Count.

ODT.Text. P.Prod_Description. S. ShipmentJMe FROM RecentDrderJ 0V. Drder_Details 00. Products P. Shipments S.

Addresses A. Code_Translations ODT. Customers C WHERE UPPER(0V.CustomerJ_ast_Name) LIKE :last_name||T AND UPPERtOV. CustomerJi rstjlame) LIKE :first_name||X AND 0D.0rder_ID = 0V.OrderJD AND 0V.CustomerJD = C.CustomerJD AND 0D.ProductJD = P.Product ID(+)

AND 0D.ShipmentJD = S.ShipmentJDC+)

AND S.AddressJD = A.AddressJDM

AND OD.StatusCode = ODT.Code

AND ODT.CodeJype = '0RDER_DETAIL_STATUS'

ORDER BY 0V.CustomerJD. OV.OrderJD Desc. S.ShipmentJD. 0D.OrderJletailJD

К сожалению, этот код не позволяет получить тот же результат, что и исходный запрос, из-за специфики внешнего соединения с представлением. В частности, исходный запрос возвращает значение Shi pmentJMe, равное null, если полное представление, включая соединение с Addresses, не может успешно соединиться с OrderJMai Is. Таким образом, если для перевозки (shipment) не указано допус-
Предыдущая << 1 .. 115 116 117 118 119 120 < 121 > 122 123 124 125 126 127 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100