Для чего нужны просмотры?

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

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

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

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

1) Чем полезен вид?

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

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

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

CREATE VIEW AS
      SELECT * FROM tblData

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

создать представление union_table1_table2_v как
выбрать a, b из table1
union
выбрать a, b из table2

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

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

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

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

OP спросил, есть ли ситуации, в которых может возникнуть соблазн использовать представление, но это не подходит.

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

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

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

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

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

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

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

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

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

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

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

Пример:

ТАБЛИЦА A:

• мне бы
• Информация

ВИД на ТАБЛИЦУ A:

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

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

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