Зачем создавать представление в базе данных?

среди прочего, его можно использовать для обеспечения безопасности. Если у вас есть таблица" клиент", вы можете предоставить всем своим продавцам доступ к имени, адресу, zipcode и т. д. поля, но не credit_card_number. Можно создать представление, включающее только столбцы, к которым требуется доступ, а затем предоставить им доступ в представлении.

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

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

редактировать

в порядке разработки, если бы у меня была база данных, в которой некоторые из субъектов были лицом, компанией, ролью, типом владельца, заказом, детализацией заказа, адресом и телефоном, где таблица person хранила как сотрудников, так и контакты, а таблицы address и phone хранили номера телефонов как для лиц, так и для компаний, и команда разработчиков мне было поручено создавать отчеты (или делать отчетные данные доступными для не-разработчиков), такие как продажи по сотрудникам, или продажи по клиентам, или продажи по регионам, продажи по месяцам, клиенты по Штатам и т. д. Я бы создал набор представлений, которые де-нормализовали отношения между объектами базы данных, чтобы было доступно более интегрированное представление (без каламбура) реальных объектов. Некоторые из преимуществ могут включать:

1. сокращение избыточности в письменной форме запросы
2. установление стандарта для связанных объектов
3. предоставление возможности оценка и максимизация производительности для сложных вычислений и соединений (например, индексирование на схематических представлениях в MSSQL)
4. сделать данные более доступными и интуитивно понятный для членов команды и не-разработчиков.

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

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

Crystal reports, похоже, предпочитает использовать представления для сохраненных процессов, поэтому люди, которые делают много отчетов, как правило, используют много представлений

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

одним из основных преимуществ представления над хранимой процедурой является то, что вы можете использовать представление так же, как вы используете таблицу. А именно, представление может быть указано непосредственно в FROM пункт запроса. Е. Г., SELECT * FROM dbo.name_of_view.

практически любым другим способом хранимые процедуры являются более мощными. Вы можете передать параметры, в том числе out параметры, которые позволяют эффективно возвращать сразу несколько значений, вы можете сделать SELECT, INSERT, UPDATE и DELETE операции и т. д. так далее.

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

вот довольно полезная статья на эту тему:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDIT: кстати, этот вид поднимает вопрос: какое преимущество имеет представление над табличной функцией? У меня нет действительно хорошего ответа на это, но я отмечу, что синтаксис T-SQL для создания представления проще, чем для табличной функции, и пользователи вашей базы данных могут быть более знакомы с представлениями.

Он может функционировать как хороший "средний человек" между вашим ORM и вашими таблицами.

пример:

У нас была таблица Person, которую нам нужно было изменить структуру на ней, чтобы столбец SomeColumn был перемещен в другую таблицу и имел отношение один ко многим.

однако большая часть системы, в отношении человека, все еще использовала SomeColumn как одну вещь, а не много вещей. Мы использовали вид, чтобы принести все SomeColumns вместе и поместили его в вид, который сработал отлично.

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

вот две общие причины:

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

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

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

еще одна причина-ограничить данные разными пользователями. Так, например:

Table1: Colums-USER_ID; имя пользователя; SSN

пользователи Admin могут иметь privs в фактической таблице, но пользователи, к которым вы не хотите иметь доступ, чтобы сказать SSN, вы создаете представление как

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

тогда дайте им privs для доступа к представлению, а не к таблице.

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

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

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

/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview 
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;

/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1

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

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

вы также можете создавать встроенные пользовательские функции, которые логически работают как параметризованные представления или представления с параметрами в условиях поиска WHERE-clause. Дополнительные сведения см. В разделе Inline User-defined Функции.

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

для экспорта и импорта данных Представления можно использовать для экспорта данных в другие приложения. Например, можно использовать таблицы магазины и продажи в базе данных pubs для анализа данных продаж с помощью Microsoft® Excel. Для этого можно создать представление на основе таблиц магазины и продажи. Затем можно использовать утилиту bcp для экспорта данных, определенных представлением. Данные также можно импортировать в определенные представления из файлов данных с помощью утилиты bcp или оператор BULK INSERT при условии, что строки могут быть вставлены в представление с помощью инструкции INSERT. Дополнительные сведения об ограничениях на копирование данных в представления см. В разделе вставка. Дополнительные сведения об использовании утилиты bcp и инструкции BULK INSERT для копирования данных в представление и из представления см. В разделе копирование в представление или из представления.

Для Объединения Секционированных Данных Оператор UNION set Transact-SQL можно использовать в представлении для объединения результатов двух или более запросов из отдельных таблиц в один результирующий набор. Это отображается пользователю как одна таблица, называемая секционированным представлением. Например, если одна таблица содержит данные о продажах для Вашингтона, а другая таблица содержит данные о продажах для Калифорнии, можно создать представление из объединения этих таблиц. Представление представляет данные о продажах для обоих регионов. Чтобы использовать секционированные представления, необходимо создать несколько одинаковых таблиц, указав ограничение для определения диапазона данных, которые могут быть добавлены в каждую таблицу. Этот затем с помощью этих базовых таблиц создается представление. При запросе представления SQL Server автоматически определяет, на какие таблицы влияет запрос, и ссылается только на эти таблицы. Например, если запрос указывает, что требуются только данные о продажах для штата Вашингтон, SQL Server считывает только таблицу, содержащую данные о продажах Вашингтона; другие таблицы недоступны.

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

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

Секционированные представления обновляются, если выполняется одно из этих условий: Вместо триггера определяется в представлении с логикой для поддержки инструкций INSERT, UPDATE и DELETE.

операторы view и INSERT, UPDATE и DELETE следуют правилам, определенным для обновляемых секционированных представлений. For more сведения см. В разделе Создание Секционированного представления.

https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

когда я хочу увидеть снимок таблицы(ов) и/или посмотреть (в сторону)

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

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

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

Это не отвечает на ваш вопрос точно, но я подумал, что стоит упомянуть Материализованные Представления. Мой опыт в основном с Oracle но предположительно SQL-сервер довольно похож.

мы использовали что-то подобное в нашей архитектуре для решения проблем производительности XML. Наши системы разработаны с большим количеством данных, хранящихся в виде XML в строке, и приложениям может потребоваться запросить определенные значения внутри нее. Обработка множества XMLTypes и запуск XPaths через большое количество строк оказывает большое влияние на производительность, поэтому мы используем форму материализованных представлений для извлечения требуемых узлов XML в реляционную таблицу при каждом изменении базовой таблицы. Это эффективно обеспечивает физический моментальный снимок запроса в данный момент времени в отличие от стандартных представлений, которые будут выполнять запрос по требованию.

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

одна любопытная вещь о представлениях заключается в том, что они рассматриваются Microsoft Access как таблицы: когда вы присоединяете интерфейс Microsoft Access к базе данных SQL с помощью ODBC, вы видите таблицы и представления в списке доступных таблиц. Поэтому, если вы готовите сложные отчеты в MS Access, вы можете позволить SQL server выполнять присоединение и запросы и значительно упростить свою жизнь. То же самое для подготовки запроса в MS Excel.

У меня есть только 10 или около того представлений в моих производственных базах данных. Я использую несколько для столбцов, которые я использую все время. Один набор я использую из 7 таблиц, некоторые с внешними соединениями и вместо того, чтобы переписывать, что постоянно мне нужно только вызвать это представление в select и сделать одно или 2 соединения. Для меня это просто экономия времени.

Я создаю xxx, который отображает все отношения между основной таблицей (например, таблицей продуктов) и ссылочными таблицами (например, ProductType или ProductDescriptionByLanguage). Это создаст представление, которое позволит мне получить продукт и все его детали, переведенные с его внешних ключей на его описание. Затем я могу использовать ORM для создания объектов, чтобы легко создавать сетки, поля со списком и т. д.

подумайте об этом как о рефакторинге схемы базы данных.

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

мы создаем представление для ограничения или ristrict доступа ко всем строкам / столбцам в таблице.Если владелец хочет,чтобы только определенные или ограниченные строки/столбец были общими, он создаст представление с этим столбцом.