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

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

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

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

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

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

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

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

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

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

Помимо всего прочего, его можно использовать для безопасности. Если у вас есть таблица «customer», возможно, вы захотите предоставить всем своим продавцам доступ к полям name, address, zipcode и т. Д., Но не credit_card_number. Вы можете создать представление, включающее только те столбцы, к которым им необходим доступ, и затем предоставить им доступ к представлению.

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

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

РЕДАКТИРОВАТЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

Объединить разделенные данные Оператор набора Transact-SQL 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

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

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

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

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

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

Таблица 1: Столбцы - USER_ID; USERNAME; SSN

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

CREATE VIEW USERNAMES AS SELECT user_id, имя пользователя FROM Table1;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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