Главная » Microsoft SQL Server, Базы данных » Вложенные представления

0

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

Следующее представление использует представление vEventList и добавляет предложение WHERE для ограничения результатов теми событиями, которые будут иметь место в последующие 30 дней:

CREATE VIEW dbo.vEventList3Odays AS

SELECT dbo.vEventList.EventCode, LastName, FirstName FROM dbo.vEventList JOIN dbo.Event

ON vEventList.EventCode = Event.EventCode WHERE Event.DateBegin

BETWEEN GETDATEO and GETDATEO +30

В данном примере представление vEventList вложено в vEventList3 0Days. Еще один способ выразить отношение— это определить зависимость представления vEvent3 0Days от vEventList. (В утилите Management Studio зависимости объектов можно просмотреть после выбора в контекстном меню объекта пункта All Tasks^Display Dependencies.) На рис. 14.2 показаны зависимости и вложенное представление.

Дополнительная Еще одним типом высокотехнологичных зависимостей является разделенное информация представление. Оно объединяет данные, разбитые на несколько сегментированных таблиц, из соображений повышения производительности. Разделенные представления мы рассмотрим в главе 53.

Представления являются не единственным средством вложения инструкций SELECT. Подзапросы и общие табличные выражения поставляют данные в виде таблиц или управляемых

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

Puc. 14.2. Цепочка зависимостей легко распознается в диалоговом окне Dependencies. В данном примере мы видим, что представление vEventList3ODays включает в себя вложенное представление vEventList

SELECT E.EventCode, LastName, FirstName FROM

(SELECT dbo.CustomerType.CustomerTypeName,

dbo.Customer.LastName, dbo.Customer.FirstName, dbo.Customer.Nickname,

dbo.Event_mm_Customer.ConfirmDate, dbo.Event.EventCode, dbo.Event.DateBegin, dbo.Tour.TourName, dbo.BaseCamp.BaseCampName, dbo.Event.Comment FROM dbo.Tour INNER JOIN dbo.Event ON dbo.Tour.TourlD = dbo.Event.TourlD INNER JOIN dbo.Event_mm_Customer ON dbo.Event.EventID = dbo.Event_mm_Customer.EventID INNER JOIN dbo.Customer ON dbo.Event_mm_Customer.CustomerlD = dbo.Customer.CustomerlD LEFT OUTER JOIN dbo.CustomerType ON dbo.Customer.CustomerTypeID = dbo.CustomerType.CustomerTypeID INNER JOIN dbo.BaseCamp ON dbo.Tour.BaseCampID = dbo.BaseCamp.BaseCampID ) E

JOIN dbo.Event

ON E.EventCode = Event.EventCode WHERE Event.DateBegin BETWEEN GETDATEO and GETDATEO +30

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

Пополнительная Об использовании подзапросов и общих табличных элементов (СТЕ) см. в гла-

информация ве 10.

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

Рис. 14.3. Синонимы можно создавать и настраивать в окне Object Explorer утилиты Management Studio

Использование синонимов

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

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

Резюме

Представления являются ничем иным, как сохраненными запросами SELECT. В этом нет ничего магического. Любая допустимая инструкция SELECT может быть сохранена как представление, включая свои сложные объединения, подзапросы и итоговые функции.

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

Работа с распределенными запросами

Данные редко находятся в одном месте. В современном мире большинство новых проектов подключается к существующим источникам данных или, по крайней мере, расширяется за счет них. Вообще-то, это не является проблемы. SQL Server позволяет считывать данные из множества разных источников и записывать их туда. Гетерогенные объединения даже позволяют объединять данные SQL Server и электронных таблиц Excel.

SQL Server предлагает несколько различных методов доступа к внешним по отношению к текущей базе данным. От простой ссылки на другую локальную базу данных до выполнения сквозных запросов, которые задействуют другую базу данных с архитектурой “клиент/сервер’’, — все это позволяет осуществить SQL Server.

Несмотря на то что SQL Server решает технические проблемы запросов к внешним данным, если две системы на самом деле обслуживаются разными приложениями, то прямое обращение к внешнему хранилищу данных в большинстве случаев нарушает принцип инкапсуляции. Таким образом, одновременное использование двух источников данных снижает гибкость архитектуры. Во многих программистских фирмах эта технология не находит поддержки. Вместо этого обмен данными осуществляется с помощью XML, SOAP и SOA, о которых мы говорили в главе 1 и еще раз к ним вернемся в главе 32.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии