Для чего нужны виды?
Я просто пытаюсь получить общее представление о том, для чего используются представления в РСУБД. То есть я знаю, что такое вид и как его создать. Я также знаю, для чего я их использовал в прошлом.
Но я хочу убедиться, что у меня есть полное понимание того, для чего представление полезно и для чего представление не должно быть полезным. Более конкретно:
- Для чего полезен вид?
- Есть ли ситуации, в которых заманчиво использовать представление, когда вы не должны его использовать?
- Зачем вам использовать представление вместо чего-то вроде табличной функции или наоборот?
- Существуют ли обстоятельства, которые могут быть полезны для представления, которые не очевидны на первый взгляд?
(И, к сведению, некоторые из этих вопросов намеренно наивны. Это частично проверка концепции.)
14 ответов
1) Для чего нужен вид?
IOPO только в одном месте
• Независимо от того, рассматриваете ли вы сами данные или запросы, которые ссылаются на объединенные таблицы, использование представления позволяет избежать ненужной избыточности.
• Представления также обеспечивают уровень абстрагирования, предотвращающий прямой доступ к таблицам (и получающиеся в результате наручники, ссылающиеся на физические зависимости). На самом деле, я думаю, что хорошей практикой является предоставление только абстрактного доступа к вашим базовым данным (с использованием представлений и табличных функций), включая такие представления, какCREATE VIEW AS
SELECT * FROM tblData
1 Я должен признать, что в этом совете есть много слов "делай, как я говорю; не так, как я";)
2) Есть ли ситуации, в которых заманчиво использовать представление, когда вы не должны его использовать?
Производительность в представлении соединений раньше была проблемой (например, SQL 2000). Я не эксперт, но я об этом давно не беспокоился. (И при этом я не могу думать о том, где я в настоящее время использую соединения представления.)
Другая ситуация, когда представление может быть избыточным, - это когда на представление ссылаются только из одного вызывающего местоположения и вместо него можно использовать производную таблицу. Точно так же, как анонимный тип предпочтительнее класса в.NET, если анонимный тип используется / упоминается только один раз.
• См. Описание производной таблицы по адресу http://msdn.microsoft.com/en-us/library/ms177634.aspx.
3) Почему вы используете представление вместо чего-то вроде табличной функции или наоборот?
(Помимо соображений производительности) Табличная функция функционально эквивалентна параметризованному представлению. Фактически, общий простой случай использования табличной функции - просто добавить фильтр предложения WHERE к уже существующему представлению в одном объекте.
4) Существуют ли какие-либо обстоятельства, которые могут быть полезны для представления, которые не очевидны с первого взгляда?
Я не могу думать ни о каких неявных применениях макушки головы. (Полагаю, если бы я мог, это сделало бы их очевидными;)
В некотором смысле представление похоже на интерфейс. Вы можете изменить базовую структуру таблицы так, как вам хочется, но представление дает возможность не менять код.
Представления - хороший способ предоставить что-то простое авторам отчетов. Если ваши бизнес-пользователи хотят получить доступ к данным из чего-то вроде Crystal Reports, вы можете дать им некоторые представления в своей учетной записи, которые упростят данные - возможно, даже денормализуют их для них.
Представления могут использоваться для обеспечения безопасности (т. Е. Пользователи могут иметь доступ к представлениям, которые имеют доступ только к определенным столбцам в таблице), представления могут обеспечивать дополнительную безопасность для обновлений, вставок и т. Д. Представления также предоставляют способ псевдонимов имен столбцов (как это делают sp's), но представления более изолированы от фактической таблицы.
В каком-то смысле взгляды денормализуются. Денормализация иногда необходима для предоставления данных более значимым образом. Это то, что многие приложения делают в любом случае посредством моделирования предметной области в своих объектах. Они помогают представлять данные таким образом, чтобы они более точно соответствовали бизнесу.
В дополнение к тому, что заявили другие, представления также могут быть полезны для удаления более сложных SQL-запросов из приложения.
В качестве примера вместо того, чтобы в приложении делали:
sql = "выберите a, b из таблицы1 объединение выберите a, b из таблицы2";
Вы можете абстрагировать это для представления:
создать представление union_table1_table2_v как
выберите a, b из таблицы 1
союз
выберите a, b из таблицы2
а в коде приложения просто есть:
sql = "выберите a, b из union_table1_table2_v";
Также, если структуры данных когда-либо изменятся, вам не придется менять код приложения, перекомпилировать и повторно развертывать. Вы бы просто изменили представление в БД.
Представления скрывают сложность базы данных. Они хороши по многим причинам и полезны во многих ситуациях, но если у вас есть пользователи, которым разрешено писать свои собственные запросы и отчеты, вы можете использовать их в качестве гарантии, чтобы они не отправляли плохо разработанные запросы с неприятными декартовыми объединениями, которые уничтожают ваш сервер базы данных.
ОП спросила, были ли ситуации, когда было бы заманчиво использовать представление, но это не подходит.
То, для чего вы не хотите использовать представление, является заменой сложных объединений. То есть не позволяйте своей привычке процедурного программирования разбивать проблему на более мелкие части, чтобы привести вас к использованию нескольких представлений, объединенных вместе, вместо одного большего объединения. Это убьет эффективность механизма базы данных, поскольку он выполняет несколько отдельных запросов, а не один больший.
Например, предположим, что вы должны объединить таблицы A, B, C и D вместе. Вы можете испытать желание сделать представление из таблиц A и B и представление из C & D, а затем объединить два представления вместе. Гораздо лучше просто объединить A, B, C и D в одном запросе.
Представления могут централизовать или консолидировать данные. Где я нахожусь, у нас есть несколько различных баз данных на нескольких разных связанных серверах. Каждая база данных содержит данные для разных приложений. Несколько из этих баз данных содержат информацию, относящуюся к ряду различных приложений. В этих условиях мы создадим представление в базе данных этого приложения, которое просто извлекает данные из базы данных, где эти данные действительно хранятся, так что запросы, которые мы пишем, не выглядят так, как будто они передаются по разным базам данных.
Ответы до сих пор верны - представления хороши для обеспечения безопасности, денормализации (хотя в этом случае много боли в случае неправильного выполнения), абстракции модели данных и т. Д.
Кроме того, представления обычно используются для реализации бизнес-логики (устаревший пользователь - это пользователь, который не входил в систему в течение последних 40 дней, такого рода вещи).
Представления сохраняют много повторяющихся сложных операторов JOIN в ваших сценариях SQL. Вы можете просто инкапсулировать некоторое сложное JOIN в некотором представлении и вызывать его в своем операторе SELECT, когда это необходимо. Иногда это было бы удобно, прямо и проще, чем выписывать операторы соединения в каждом запросе.
Представление - это просто сохраненный оператор SELECT с именем. Думайте о представлениях как о функциях библиотеки.
Я хотел бы выделить использование представлений для отчетности. Часто возникает конфликт между нормализацией таблиц базы данных для повышения производительности, особенно для редактирования и вставки данных (использование OLTP), и денормализацией для уменьшения количества объединений таблиц для запросов для создания отчетов и анализа (использование OLAP). По необходимости OLTP обычно побеждает, потому что ввод данных должен иметь оптимальную производительность. Таким образом, создание представлений для оптимальной производительности отчетов может помочь удовлетворить оба класса пользователей (ввод данных и средства просмотра отчетов).
Я помню очень длинный SELECT, в котором участвовало несколько профсоюзов. Каждый UNION включал в себя объединение с таблицей цен, которая была создана на лету с помощью SELECT, который сам по себе был довольно длинным и трудным для понимания. Я думаю, что было бы неплохо иметь представление о том, чтобы создать таблицу цен. Это сократило бы общий SELECT примерно наполовину.
Я не знаю, будет ли БД оценивать представление один раз или один раз каждый раз вызывался. Кто-нибудь знает? Если первое, использование представления улучшит производительность.
В любое время вам нужно [my_interface]!= [User_interface].
Пример:
ТАБЛИЦА А:
- Я бы
- Информация
ВИД на ТАБЛИЦУ А:
- Информация для покупателей
Таким способом вы можете скрыть идентификатор от клиента и переименовать информацию в более подробное имя одновременно.
Представление будет использовать базовый индекс для идентификатора первичного ключа, поэтому вы не увидите потери производительности, просто улучшите абстракцию запроса select.