Чем хороши просмотры?

Question

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

Но я хочу убедиться, что у меня есть полное понимание того, для чего представление полезно, а для чего оно бесполезно.Более конкретно:

1. Чем полезно представление?
   • Существуют ли ситуации, в которых возникает соблазн использовать представление, хотя его использовать не следует?
   • Зачем вам использовать представление вместо чего-то вроде функции с табличным значением или наоборот?
   • Существуют ли какие-либо обстоятельства, при которых представление может оказаться полезным, но не очевидные на первый взгляд?

(И, кстати, некоторые из этих вопросов намеренно наивны.Частично это проверка концепции.)

Answer 1

1) Чем полезно представление?

IOPO Только в одном месте

• Независимо от того, рассматриваете ли вы сами данные или запросы, ссылающиеся на объединенные таблицы, использование представления позволяет избежать ненужной избыточности.

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

CREATE VIEW AS
      SELECT * FROM tblData

¹Я должен признать, что существует немало фраз: «Делай, как я говорю;не так, как я» в этом совете ;)

2) Существуют ли ситуации, в которых возникает соблазн использовать представление, хотя его не следует использовать?

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

Другая ситуация, когда представление может быть излишним, — это когда на представление ссылаются только из одного места вызова и вместо него можно использовать производную таблицу.Точно так же, как анонимный тип предпочтительнее класса в .NET, если анонимный тип используется/ссылается только один раз.

• См. описание производной таблицы в http://msdn.microsoft.com/en-us/library/ms177634.aspx.

3) Зачем вам использовать представление вместо чего-то вроде функции с табличным значением или наоборот?

(Помимо соображений производительности) Функция с табличным значением функционально эквивалентна параметризованному представлению.Фактически, общий вариант использования простой функции с табличным значением — это просто добавление фильтра предложения WHERE к уже существующему представлению в одном объекте.

4) Есть ли какие-либо обстоятельства, при которых представление может быть полезным, но не очевидные на первый взгляд?

Я не могу придумать какого-либо неочевидного использования макушки головы.(Думаю, если бы я мог, это сделало бы их очевидными;)

Answer 2

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

Представления — это хороший способ предоставить авторам отчетов что-то простое.Если ваши бизнес-пользователи хотят получить доступ к данным из чего-то вроде Crystal Reports, вы можете предоставить им некоторые представления в их учетной записи, которые упрощают данные - возможно, даже денормализуют их для них.

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

В дополнение к тому, что заявили другие, представления также могут быть полезны для удаления из приложения более сложных SQL-запросов.

Например, вместо выполнения в приложении:

SQL = "Выберите A, B из Table1 Union Select A, B из Table2";

Вы можете абстрагировать это до представления:

создать представление Union_table1_table2_v как
выберите a,b из таблицы 1
союз
выберите a,b из таблицы 2

и в коде приложения просто введите:

sql = "выберите a, b из Union_table1_table2_v";

Кроме того, если структуры данных когда-либо изменятся, вам не придется менять код приложения, перекомпилировать и повторно развертывать его.вы просто измените представление в БД.

Answer 7

ФП спросил, были ли ситуации, когда было бы заманчиво использовать представление, но это неуместно.

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

Например, предположим, что вам нужно объединить таблицы A, B, C и D.У вас может возникнуть соблазн создать представление из таблиц A и B и представление из C и D, а затем соединить два представления вместе.Гораздо лучше просто объединить A, B, C и D в одном запросе.

Answer 8

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

Answer 9

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

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

Answer 10

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

Answer 11

Представление — это просто сохраненный оператор SELECT с именем.Думайте о представлениях как о библиотечных функциях.

Answer 12

Я хотел подчеркнуть использование представлений для составления отчетов.Часто возникает конфликт между нормализацией таблиц базы данных для повышения производительности, особенно при редактировании и вставке данных (используется OLTP), и денормализацией для уменьшения количества объединений таблиц для запросов для отчетов и анализа (используется OLAP).Разумеется, обычно побеждает OLTP, поскольку ввод данных должен иметь оптимальную производительность.Таким образом, создание представлений для оптимальной производительности отчетов может помочь удовлетворить оба класса пользователей (ввод данных и просмотрщики отчетов).

Answer 13

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

Я не знаю, будет ли БД оценивать представление один раз или один раз при каждом вызове.Кто-нибудь знает?В первом случае использование представления улучшит производительность.

Answer 14

В любое время вам понадобится [my_interface] != [user_interface].

Пример:

ТАБЛИЦА А:

• идентификатор
• Информация

ПРОСМОТР ТАБЛИЦЫ А:

• Информация для клиентов

это способ скрыть идентификатор от клиента и переименовать информацию в более подробное имя одновременно.

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