Я читаю Библию SQL Server 2008, и я освещаю раздел мнений. Но автор действительно не объясняет цели взглядов. Что хорошо использовать для просмотров? Должен ли я использовать их на своем веб-сайте и в чем их преимущества?
Что является хорошей причиной для использования представлений SQL?
Ответ 1
Другое использование, о котором, похоже, не упоминалось ни в одном из предыдущих ответов, - более простое развертывание изменений структуры таблицы.
Скажем, вы хотите удалить таблицу (T_OLD
), содержащую данные для активных пользователей, и вместо этого использовать новую таблицу с аналогичными данными (названную T_NEW
), но в которой есть данные как для активных, так и для неактивных пользователей, с одним дополнительным столбцом active
.
Если в вашей системе есть gazillion запросов, выполняющих SELECT whatever FROM T_OLD WHERE whatever
, у вас есть два варианта развертывания:
1) Холодная Турция - Измените БД, и в то же время измените, протестируйте и выпустите многочисленные фрагменты кода, которые содержали указанный запрос. ОЧЕНЬ сложно сделать (или даже координировать), очень рискованно. Плохо.
2) Постепенно - измените базу данных, создав таблицу T_NEW
, отбросив таблицу T_OLD
и вместо этого создав VIEW под названием T_OLD
, который на 100% имитирует таблицу T_OLD
(например, запрос представления SELECT all_fields_except_active FROM T_NEW WHERE active=1
).
Это позволит вам избежать выпуска ЛЮБОГО кода, который в настоящее время выбирается из T_OLD
, и вносить изменения для переноса кода из T_OLD
в T_NEW
на досуге.
Это простой пример, есть и другие, более вовлеченные.
Постскриптум С другой стороны, вам, вероятно, следовало бы иметь API хранимых процедур вместо прямых запросов из T_OLD
, но это не всегда так.
Ответ 2
(Скопировано из первого учебного пособия, которое появилось в поиске Google (ссылка теперь неактивна), но оно обладает всеми преимуществами, которые я бы сам набрал вручную.)
Представления имеют следующие преимущества:
- Безопасность - представления могут быть доступны для пользователей, в то время как базовые таблицы не доступны напрямую. Это позволяет администратору базы данных предоставлять пользователям только те данные, которые им нужны, при этом защищая другие данные в той же таблице.
- Простота. Представления могут использоваться для скрытия и повторного использования сложных запросов.
- Упрощение или уточнение имени столбца. Представления могут использоваться для предоставления псевдонимов имен столбцов, чтобы сделать их более запоминающимися и/или значимыми.
- Ступенька - Представления могут стать ступенькой в "многоуровневом" запросе. Например, вы можете создать представление запроса, в котором будет подсчитано количество продаж, совершенных каждым продавцом. Затем вы можете запросить это представление, чтобы сгруппировать продавцов по количеству продаж, которые они совершили.
Ответ 3
Некоторые причины из Wikipedia:
Представления могут обеспечить преимущества перед таблицами:
- Представления могут представлять собой подмножество данных, содержащихся в таблице
- Представления могут объединяться и упрощать несколько таблиц в одну виртуальную таблицу
- Представления могут действовать как агрегированные таблицы, где агрегат базы данных агрегатируется данные (сумма, среднее значение и т.д.) и представлены расчетные результаты как часть данных
- Представления могут скрывать сложность данных; например, представление может отображаться как Sales2000 или Sales2001, прозрачно разбивая фактическую базовую таблицу.
- Представления занимают очень мало места для хранения; база данных содержит только определение представления, а не копия всех данных, которые она представляет.
- В зависимости от используемого механизма SQL представления могут обеспечивать дополнительную безопасность
- Представления могут ограничить степень воздействия таблицы или таблиц во внешний мир
Ответ 4
ПРОСМОТРЫ могут использоваться как разделы многократного использования SELECT/CODE, которые могут быть включены в другие элементы выбора/запросов, которые необходимо объединить, и использовать различные различные фильтры, без необходимости воссоздавать весь SELECT каждый раз.
Это также помещает логику в одно место, так что вам не нужно менять ее по всей базе кода.
Посмотрите
Выбор хранимых процедур, функций, представлений, триггеров, встроенного SQL
Основная красота взгляда заключается в том, что он может использоваться как таблица в большинстве ситуаций, но, в отличие от таблицы, она может инкапсулировать очень сложные вычисления и обычно используемые соединения. Он также может использовать почти любой объект в db за исключением хранимых процедур. Просмотры наиболее полезны, когда вам всегда нужно присоединиться к одному и тому же набору таблиц. Заказ с подробной информацией о заказе поля итогового расчета и т.д.
Ответ 5
Вид - это слой абстракции, и он выполняет то, что делает любой хороший уровень абстракции, включая инкапсуляцию схемы базы данных и защиту вас от последствий изменения внутренних деталей реализации.
Это интерфейс.
Ответ 6
Вот очень распространенное использование использования представлений для ограничения сущности по некоторым критериям.
Таблица: USERS содержит всех пользователей
View: ACTIVE_USERS содержит всех пользователей, за исключением тех, кто заблокирован, заблокирован, ждет активации и не соответствует каким-либо критериям, которые вы можете определить в будущем в рамках активных требований. Это делает ненужным удалять любые строки из таблицы USERS, если вы не хотите, потому что ACTIVE_USERS всегда могут скрывать нежелательные строки.
Таким образом, вы можете использовать таблицу на своих страницах управления пользователями, но остальная часть приложения может использовать ACTIVE_USERS, поскольку они могут быть единственными пользователями, которые должны иметь возможность выполнять процессы и получать доступ/изменять данные.
Ответ 7
Представления могут позволять вам объединять данные из нескольких разных таблиц и форматировать их (комбинировать поля, давать более значимые имена полей и т.д.), чтобы это стало проще для конечных пользователей. Это абстракция модели базы данных. Они также могут использоваться для предоставления пользователям доступа к данным в таблице без прямого доступа к самой таблице.
Ответ 8
Вот некоторые из многих причин непосредственного использования вида, а не таблицы
- Простота. Представления могут использоваться для скрытия сложных запросов.
- Безопасность - просмотр может скрыть важную информацию от конечного пользователя, создав представление для некоторых выбранных столбцов.
- Безопасность - защищенная таблица, чтобы изменить ее структуру с помощью VIEW.
- Резервирование. Сокращение избыточного кода в каждой процедуре/запросе с помощью общего вида.
- Вычисление. Все вычисления можно выполнить один раз в запросе вида.
- Значимое имя. Таблица может иметь имя для id, например, tbl_org_emp_id, которое может иметь псевдоним, например [Employee No] или какое-либо значимое имя.
Ответ 9
Небольшой список общих причин/использования:
-
использовать их для изменения формата или "посмотреть" данные (т.е. вы можете присоединиться к имя и фамилия вместе)
выполнять вычисления или другие поисковые запросы по данным
денормализовать данные (извлечь данные из несколько таблиц в одном месте)
Ответ 10
Не всегда верно, что вы не можете обновить базовую таблицу представления.
Например, попробуйте
создать представление theyshallnotpass как select * from
и попробуйте обновление для неприятного сюрприза...
(MSSQL)
Ответ 11
Взгляды злы! Избегайте их, если это возможно, и используйте только по причине, упомянутой DVK - временная миграция данных.
Вы должны понимать, что в базе данных со 100 таблицами трудно запомнить цель каждой таблицы. Теперь, если вы добавите еще 300 просмотров, это станет полным беспорядком. Чем "View lovers" имеют тенденцию использовать вложенные представления, а затем использовать вложенные представления в хранимых процедурах. Я лично работаю теперь с базой данных, где есть представления, вложенные в глубину 4 раза! Поэтому, чтобы понять простейшую логику хранимой процедуры, я должен сначала просмотреть все взгляды.