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

Когда и почему кто-то решает, что им нужно создать представление в своей базе данных? Почему бы просто не запустить обычную хранимую процедуру или выбрать?

Ответ 1

Представление предоставляет несколько преимуществ.

1. Виды могут скрывать сложность

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

2. Представления могут быть использованы в качестве механизма безопасности

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

3. Представления могут упростить поддержку устаревшего кода

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

ИЗМЕНИТЬ

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

  • Уменьшение избыточности при написании запросов
  • Установление стандарта для связанных объектов
  • Предоставление возможностей оценивать и максимизировать производительность для сложных вычислений и объединений (например, индексирование в представлении Schemabound в MSSQL)
  • Обеспечение доступности данных и интуитивно понятный для членов команды и не-разработчиков.

Ответ 5

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

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

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

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

Ответ 6

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

РЕДАКТИРОВАТЬ:. Кстати, этот вопрос поднимает вопрос, какое преимущество имеет представление над табличной функцией? У меня к этому нет хорошего ответа, но я хочу заметить, что синтаксис T-SQL для создания представления проще, чем для функции, ориентированной на таблицу, и пользователи вашей базы данных могут быть более знакомы с представлениями.

Ответ 7

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

Пример:

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Таблица 1: Colums - USER_ID; USERNAME; SSN

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

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

/* 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

Ответ 13

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

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

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

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

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

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

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

Ответ 22

Подумайте об этом как о реорганизации вашей схемы базы данных.

Ответ 23

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

Ответ 24

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

Ответ 25

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

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

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