Для чего нужны виды?

Question

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

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

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

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

Answer 1

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

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

Answer 2

1) Для чего нужен вид?

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

& bull; Рассматриваете ли вы сами данные или запросы, которые ссылаются на объединенные таблицы, использование представления исключает ненужную избыточность.

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

CREATE VIEW AS <br/> SELECT * FROM tblData

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

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

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

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

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

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

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

4) Существуют ли какие-либо обстоятельства, которые могут быть полезны для вида, которые не очевидны на первый взгляд?

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

sql = "выберите a, b из таблицы table union выберите a, b из таблицы2 ";

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

создать представление 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 при необходимости Иногда это было бы удобно, прямо и проще, чем выписывать операторы соединения в каждом запросе.