Что такое вьюха в программировании

Что такое представления VIEWS в базах данных? И зачем они нужны?

Многие начинающие администраторы и программисты баз данных, да и просто системные администраторы, которые обслуживают некую базу данных, не знают что такое представление или VIEWS, и зачем вообще они нужны. Сейчас мы попробуем разобраться, что же это такое.

Начнем с небольшой теории.

Что такое VIEWS?

VIEWS – представление, или, например, в PostgreSQL они называются «Видами» (т.е. Вид), русские админы часто называют их вьюхами, т.е. одно представление это вьюшка. Она представляет собой хранимый запрос к базе данных, также ее можно назвать виртуальная таблица, но в этой таблице данные не хранятся, а хранится только сам запрос. Но, тем не менее, к вьюшке можно обращаться как к обычной таблице и извлекать данные из нее.

Мы с Вами говорим о базах данных, в которых используется язык SQL, исходя из этого, можно сделать вывод, что VIEWS можно создать на данном языке. Это очень распространенный объект в базе данных, поэтому во всех СУБД есть возможность создавать представления в графическом интерфейсе путем нажатия кнопки «Создать представление» или «Создать новый вид», а также, конечно же, с использованием инструкции «CREATE VIEW».

Но перед тем как учиться создавать вьюшки, давайте поговорим о том, зачем они нужны и какие преимущества они нам дадут.

Зачем нужны представления?

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

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

Как создать представление VIEWS?

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

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

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

Полный синтаксис команды CREATE VIEW (в PostgreSQL) выглядит следующим образом:

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

У меня все, надеюсь, теперь у Вас есть представление о том, что такое VIEWS, пока!

Источник

Представления

Введение

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

Пункты для размышления

Постарайтесь ответить на предложенные вопросы. После выполнения задания попробуйте ответить на них ещё раз

Макеты/Layouts

Для совершенно нового приложения, макет application.html.erb предельно прост. Он содержит основные тэги (например и ), а также пару сниппетов для загрузки Javascript и CSS, используемых на вашей странице. Вы будете добавлять в макет дополнительный код для использования на всех ваших страницах. Обычно это навигационные меню, футеры и сниппеты для отображения сообщений flash.

Препроцессоры

Различие между и в том, что отобразит все что вернется из ERB тэгов. напротив, после выполнения кода не отобразит ни строчки, независимо от того, что вернул код.

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

В вышеприведенном коде, если пользователь залогинен, то отрендерится приблизительно такой код:

Код будет значительно короче, если пользователь не вошел в систему:

Как работают препроцессоры?

Rails обрабатывает расширения файла, начиная извне. Так что в данном случае он сначала использует для процессинга ERB, в уже затем относится к нему как к обычному файлу HTML. Это нормально, так как после ERB мы получаем чистый HTML, как мы видели выше.

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

Парциалы/Partials

Следует обратить внимание на пару особенностей синтаксиса. Файл парциала представления _user_form.html.erb начинается с нижнего подчеркивания, но вызывается с использованием основной части своего имени, как user_form в примере выше.

Передача локальных переменных в парциалы

Для использование переменной в парциале, просто отбрасываем @ и используем обычную переменную.

Неявные парциалы

И в вашем парциале:

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

Если это обычный путь, каков же магический путь Rails? Прочто укажите объект User для рендеринга напрямую, например:

Методы-помощники

Из представлений вы можете вызывать не только метод рендеринга. Есть немало методов-помощников, доступных вам из представлений. Вот несколько из наиболее известных:

#link_to

`link_to’ создает гиперссылку. Вместо:

Ресурсные тэги/Asset Tags

Как вы видели ранее в макете приложения, Rails предоставляет методы-помощники, которые создают HTML ссылки на файлы CSS или Javascript. Аналогично вы можете подтягивать в свое приложение и файлы изображений. Эти методы называются ресурсными тэгами. С понятием «Asset Pipeline» мы познакомимся немного попозже, но в основном эти тэги находят нужные файлы по их имени и создают необходимый тэг HTML.

Создаст что-то вроде:

примечание: в режиме «production», ваши CSS и javascripts будут объединены в отдельные файлы, и не волнуйтесь, если они будут называться наподобие /assets/application-485ea683b962efeaa58dd8e32925dadf

Формы

В Rails существует несколько различных помощников (хелперов), создающих формы, и мы ими воспользуемся в последующих уроках.

Ваши задания

Теперь, когда вы получили представления об основах, настало время вникнуть в детали. Материал по ссылке ниже начинается с работы контроллера, где вы должны указать, КАКОЕ представление вы должны отрендерить. Вторая же половина больше относится к работе с представлениями.

Заключение

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

Дополнительные ресурсы

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

Источник

View (программирование)

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

Содержание

Способ создания и содержимое представлений

Типичным способом создания представлений для СУБД, поддерживающих язык запросов PostgreSQL, Interbase, Microsoft SQL Server, Oracle, представление может содержать:

Использование

Представления используются в запросах к БД тем же образом, как и обычные таблицы. В случае SQL-СУБД имя представления может находиться в SQL-запросе на месте имени таблицы (в предложении FROM). Запрос из представления обрабатывается СУБД точно так же, как запрос, в котором на месте имени представления находится подзапрос, определяющий это представление. При этом СУБД с развитыми возможностями оптимизации запросов перед выполнением запроса из представления могут проводить совместную оптимизацию запроса верхнего уровня и запроса, определяющего представление, с целью минимизации затрат на выборку данных.

Использование представлений не даёт каких-то совершенно новых возможностей в работе с БД, но может быть очень удобно.

Специфические типы представлений

Некоторые СУБД имеют расширенные представления для данных, доступных только для чтения. Так, СУБД Oracle реализует концепцию «материализованных представлений» — представлений, содержащих предварительно выбранные невиртуальные наборы данных, совместно используемых в распределённых БД. Эти данные извлекаются из различных удалённых источников (с разных серверов распределённой СУБД). Целостность данных в материализованных представлениях поддерживается за счёт периодических синхронизаций или с использованием триггеров. Аналогичный механизм предусмотрен в Microsoft SQL Server версии 2000.

По самой сути представления могут быть доступны только для чтения. Тем не менее, в некоторых СУБД (например, в Oracle) представления могут быть редактируемыми, как и обычные физические таблицы. Редактирование может допускаться для представлений, выбранных из единственной физической таблицы таким образом, чтобы каждой записи в представлении соответствовала строго одна запись в таблице-источнике, а в числе полей представления был первичный ключ физической таблицы. При выполнении команд редактирования, добавления или удаления для такого представления сервер СУБД преобразует эти команды в соответствующие команды для физической таблицы-источника. Разумеется, если в представлении используется группировка записей или преобразование значений в полях, редактирование такого представления невозможно даже теоретически. Но и такие представления могут, тем не менее, редактироваться, посредством написания соответствующих триггеров (хотя осмысленность подобных операций целиком останется на совести программиста). Впрочем, редактируемые представления, как и возможность создания триггеров для представлений, поддерживают лишь немногие СУБД.

Источник

Представление (VIEW) в T-SQL – описание и примеры использования

Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами поговорим о таких объектах Microsoft SQL Server, как «Представления», Вы узнаете, что это за объекты, для чего они нужны, а также как создавать, изменять и удалять представления на языке T-SQL.

Представление (VIEW) в Microsoft SQL Server

Представление (VIEW) – это объект базы данных Microsoft SQL Server, который хранит в себе запрос SELECT и в случае обращения к данному объекту будет возвращен результирующий набор данных, который формирует запрос, указанный в определении представления.

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

Для чего нужны представления

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

Таким образом, представления нужны для:

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

Какие бывают представления

Работа с представлениями на T-SQL

Исходные данные

Сначала нам необходимо создать тестовые данные для наших примеров.

Допустим, у нас будет таблица Goods, которая хранит некую информацию о товарах, и таблица Categories, которая хранит данные о категориях товара.

Заметка! Всем тем, кто только начинает свое знакомство с языком SQL, рекомендую прочитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.

Создание представлений

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

Создается представление с помощью инструкции CREATE VIEW.

Для решения нашей задачи мы можем создать следующее представление.

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

Примечание! В представлении нельзя использовать секцию ORDER BY, т.е. сортировку, в случае необходимости, отсортировать данные Вы можете, когда будете обращаться к этому представлению. Использование ORDER BY возможно, только если указан оператор TOP.

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

Изменение представлений

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

В данном случае мы написали инструкцию ALTER VIEW, которая говорит SQL серверу, что мы хотим изменить существующий объект, затем указали название представления, чтобы сервер мог определить, какое именно представление мы хотим изменить, после ключевого слова AS мы указали новое определение представления, т.е. измененный запрос SELECT.

Чтобы отделить инструкцию изменения представления от SQL запроса на выборку, мы написали команду GO.

Удаление представлений

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

Теперь данного представления больше нет, и к нему Вы больше обратиться не сможете.

Обновляемые представления в Microsoft SQL Server

Кроме того, что к представлению можно обращаться и извлекать данные, представление позволяет еще и изменять данные базовой таблицы, такие представления называются «Обновляемые представления». Однако для этого необходимо выполнение следующих условий:

Допустим, у нас есть представление, которое возвращает список товаров. Для примера мы его назвали GoodsUpdate.

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

Мы видим, что данные успешно изменены.

Заметка! Для комплексного изучения языка SQL и T-SQL рекомендую пройти онлайн-курсы по T-SQL, на которых используется последовательная методика обучения и рассматриваются все объекты SQL Server и конструкции языка T-SQL.

На сегодня это все, надеюсь, материал был Вам интересен и полезен, до новых встреч!

Источник

3.1. Представления View

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

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

Для чего создаются вьюшки? Можно выделить следующие назначения:

3.1.1. Создание вьюшки

Для создания вью используется оператор CREATE VIEW, который в общем виде выглядит следующим образом:

Минимум, что необходимо указать, это оператор CREATE VIEW, после которого должно идти имя. Далее указываем ключевое слово AS и пишем запрос на выборку данных, который и будет отражать содержимое вьюшки.

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

Как теперь можно использовать эту вьюшку? Точно так же, как и таблицу, то есть выполнять запрос SELECT:

Результат выполнения запроса:

Вью предоставляет несколько преимуществ:

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

Вьюшки позволяют вам хранить результат комплексного запроса. Другие запросы могут использовать этот суммирующий результат.

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

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

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

Когда мы ограничиваем доступ к определенным полям, то такая защита называется вертикальной. Объекты просмотра позволяют создавать и горизонтальную защиту. Например, в таблице есть определенные пользователи, которые должны быть видны только привилегированным пользователям. У таких пользователей в поле «Категория» стоит значение 1. Если запретить прямой доступ к таблице, а для всех пользователей создать вьюшку, то можно скрыть записи. Вьюшка может выглядеть следующим образом:

В этом примере мы ограничиваем доступ к определенным записям, а не полям и такая защита называется горизонтальной.

Конечно же, вы можете создать и горизонтальную защиту и вертикальную в одном объекте просмотра. Этого нам никто запретить не может.

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

В каждой базе данных могут быть системные вьюшки, которые создаются сервером автоматически. Не советую разрешать к ним доступ, потому что они могут показать что-нибудь лишнее, что поможет хакеру поднять свои права или просто испортить данные. Системные вьюшки начинаются с префикса sys и в колонке Type списка светиться надпись System (если просматривать хранимые на сервере вью с помощью программы Enterprise Manager).

Когда вы создаете вью, SQL Server проверяет существование объектов, на которые ссылаются в объявлении вью. Ваше имя вью должно соответствовать правилам именования объектов базы данных. Вы должны именовать вьюшки так, чтобы их имена отличались от имен таблиц, и их можно было выделить среди других объектов. Это значит, что имя вью не должно конфликтовать не только с существующими объектами просмотра (View), но и с именами таблиц базы данных. Если бы можно было создать просмотр с именем tbPeoples, то следующим запрос не смог бы определить, откуда выбирать данные – из вью или из таблицы с таким именем:

Для выполнения оператора CREATE VIEW, вы должны иметь соответствующие права, например, быть владельцем базы данных. Вы также должны иметь права на выполнение оператора SELECT всех таблиц, используемых в вью. Чтобы избежать ситуации, когда владельцем вью является один человек, а владельцем таблиц другой, всеми объектами должен владеть dbo. Всегда указывайте имя dbo при создании объектов. Например, в следующем примере показано, как PhoneView, который мы рассматривали ранее в этой главе, с явным указанием владельца (dbo):

Все поля вью должны иметь имена, и они должны быть уникальными. Поэтому, необходимо во время выполнения оператора CREATE VIEW учитывать следующие особенности:

Например, давайте создадим объект просмотра, который будет считать количество различных имен в таблице. Для этого запрос будет использовать группировку и функцию count:

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

Есть еще один способ задания полей для View – в скобках после имени вьюшки:

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

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

В секции SELECT поле «idPeoples» выбирается из таблицы работников и из таблицы телефонов. Если смотреть на этот код как запрос, то ошибки нет, и он выполнится. Но если попытаться создать вью:

В ответ на это мы тут же увидим ошибку. Сервер сообщит нам о том, что поля вьюшки должны быть уникальными. Проблема опять же решается с помощью задания одному из конфликтующих полей псевдонима с уникальным именем. Например, в следующем запросе полю «idPeoples» из таблицы tbPhoneNumbers задается псевдоним PhoneNumbersID:

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

Существуют и другие ограничения на запрос SELECT, которые необходимо четко соблюдать

3.1.2. Редактирование вью

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

Оператор ALTER VIEW изменяет объявление вью. Это позволяет вам сохранить разрешения. В общем виде команда выглядит следующим образом:

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

Как видите, изменение происходит также, как и создание объекта просмотра.

3.1.3. Удаление вью

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

Можно удалять сразу несколько объектов просмотра. Следующий пример удаляет сразу три объекта:

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

3.1.4. Изменение содержимого вью

Я уже говорил о том, что с объектом просмотра можно работать также как и с простой таблицей. Это значит, что возвращаемый результат можно воспринимать как таблице и редактировать. Давайте попробуем изменить в вьюшке PhoneView фамилию работника с идентификатором 1 на Печкина:

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

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

Объект просмотра PhoneView выводит результат из трех таблиц сразу. А что, если мы хотим изменить поля из нескольких таблиц одновременно? Давайте попробуем выполнить следующий запрос:

В этом примере изменяется поле фамилии, которое находится в таблицы tbPeoples и поле названия должности из таблицы tbPosition. Если попытаться выполнить этот запрос, то сервер вернет ошибку и сообщит нам, что изменять сразу несколько полей нельзя. Именно это и есть ограничение при изменении записей.

3.1.5. Удаление строк из вью

Попробуем удалить запись из вьюшки PhoneView:

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

Давайте создадим вьюшку, которая будет выбирать записи только из одной таблицы:

Теперь попробуем удалить запись:

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

3.1.6. Опции объекта просмотра

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

Давайте создадим объект просмотра, данные которого (исходный код) будут зашифрованными в системной таблице:

Перед ключевым словом AS мы поставили опцию WITH ENCRYPTION. Теперь текст запроса просмотреть нельзя, даже если вы получите полный доступ к базе, и будете смотреть системные таблицы напрямую.

Источник