Главная » Microsoft SQL Server, Базы данных » Зачем использовать представления

0

Существует несколько мнений относительно использования представлений: от полного их игнорирования до чрезмерного использования. Принципы информационной архитектуры, которые мы рассмотрели в главе 1, могут лучше всего пояснить, где уместно использование представлений. Соответствующий принцип гласит: “информация… должна быть… представлена в удобном формате для повседневных операций и анализа пользователями, их группами и процессами…

Собственно, основной задачей представлений и является отображение данных в удобном формате.

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

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

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

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

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

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

?               Используйте представления для упрощения сложных объединений и сокрытия мистических ключей, используемых для связывания данных в схеме базы данных. Хорошо созданное представление будет отличным подспорьем в доступе пользователей к необходимым им данным.

?               Сохраняйте сложные запросы консолидации данных как представления. Так как

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

?               Присваивайте столбцам с труднопроизносимыми названиями понятные псевдонимы. Как инструкция SELECT может использовать псевдонимы и именованные диапазоны для имен таблиц и столбцов, так и представления могут использовать эту возможность для представления набора данных конечному пользователю. Например, столбец au_lname в базе данных Microsoft Pubs мало что скажет конечному пользователю, если не присвоить ему понятный псевдоним LastName (фамилия):

SELECT au_lname AS LastName FROM Pubs.dbo.Author

Теперь представление, созданное на основе указанного выше запроса, будет перечислять фамилии авторов в столбце LastName, а не au_lname, как раньше.

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

?               Тщательно планируйте представления для их долгосрочного использования.

Представления, созданные только для одной цели, быстро устаревают и только засоряют базу данных. Создавайте представления, предполагая, что они будут использоваться с предложением WHERE для выборки подмножества данных; в противном случае представление должно возвращать все множество данных. Например, представление vEventList возвращает все события; чтобы выбрать из них только конкретные, пользователь должен сопроводить его предложением WHERE.

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

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

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

Индексированные представления, поставляемые с редакцией SQL Server 2005 Enterprise, представляют собой мощное средство, создающее индекс на денормализованном множестве данных, определенных представлением. Эти индексы впоследствии могут использоваться при создании запросов, объединяющих множества данных. Данные представления используются в запросах, так что сам термин звучит несколько странно.

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

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

По теме:

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