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

 

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

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

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


Выполняя шаг 6, уже начав обработку подзапроса, необходимо закончить его, начиная с D как с ведущего узла. Следуя правилам для простых запросов, далее присоединяем SI, S3, S2 и S4 в указанном порядке. Возвращаясь к внешнему запросу и применяя обычные правила для простых запросов, находим оставшийся по-
240

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

рядок соединения как А2, BI, В2. Полный оптимальный порядок соединения, включая полусоединение — (М. Al. D1 SI. S3. S2. S4, А2. BI. В2).

ПОЧЕМУ НЕОБХОДИМО ТАК БЕСПОКОИТЬСЯ О ПОДЗАПРОСАХ?------------------------------------

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

Время от времени (хотя не так часто, как вы можете подумать) я встречаюсь с граничными случаями, когда имеет смысл попробовать разные альтернативные варианты и выбрать самый быстрый. Мой способ может прекрасно подойти и вам. Если вы не доверяете интуиции или хотите иметь твердую основу, включающую мой опыт, то формальные правила будут вам полезны. Формальные правила, приведенные в этом разделе, которые я сформулировал специально для этой книги, предназначены для обработки всего диапазона ре альных запросов с разумным компромиссом между математической безупречностью и удобством. Только объемные вычисления «в лоб» могут справиться с задачей такой сложности без применения метода проб и ошибок, но эти правила предлагают использовать некоторую автоматическую интуицию, которая так же хороша, а может быть, даже лучше моего «ленивого» подхода.

Запросы с представлениями

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

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

Это запросы, лежащие в основе представлений (то есть запросы, которые применяются для создания представлений при помощи CREATE VIEW <Имя_представле-ния> AS <Здпрос_определяющий_предстдвление>).

2. Запросы, использующие представления.

Это запросы, которые вы настраиваете, и которые база данных фактически выполняет. В этих запросах представления упоминаются во фразе FROM (например, SELECT ... FROM Viewl VI, View2 М2.... WHERE ...).

При настройке SQL представления обычно добавляют сложности в трех отношениях.

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

241

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

¦ Иногда использующие представления запросы невозможно выразить просто как эквивалентные запросы к простым таблицам. Обычно случаи, когда использующий представления запрос возвращает разные результаты из запроса к простой таблице, скрыты и редко возникают. Однако правильные результаты в этих скрытых случаях — это не те результаты, которые получает использующий представления запрос! Если запрос, использующий представления, нельзя легко разложить в эквивалентный простой запрос к таблицам, производительность чаще всего страдает, а скрытые случаи, определяющие поведение, относящееся именно к представлениям, содержат ошибки. Тем не менее, улучшение производительности с практически эквивалентным простым запросом к таблицам не должно приводить даже к небольшим изменениям функциональности, и вам нужно быть очень осторожными, чтобы не внести ошибку. (Чаще всего вы будете исправлять ошибки, а не добавлять новые, но новые ошибки будут более заметны!) Этот случай я проиллюстрирую в разделе «Внешние соединения с представлениями».
Предыдущая << 1 .. 112 113 114 115 116 117 < 118 > 119 120 121 122 123 124 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100