Я читаю библию по SQL Server 2008 и освещаю раздел представлений. Но автор толком не объясняет цель просмотров. Что хорошего в просмотрах? Стоит ли использовать их на своем веб-сайте и в чем их преимущества?
Я читаю библию по SQL Server 2008 и освещаю раздел представлений. Но автор толком не объясняет цель просмотров. Что хорошего в просмотрах? Стоит ли использовать их на своем веб-сайте и в чем их преимущества?
Ответы:
Другое использование, о котором, похоже, не упоминалось ни в одном из предыдущих ответов, - это более простое развертывание изменений структуры таблицы.
Скажем, вы хотите удалить таблицу ( T_OLD), содержащую данные для активных пользователей, и вместо этого использовать новую таблицу с аналогичными данными (названными T_NEW), но с данными как для активных, так и для неактивных пользователей, с одним дополнительным столбцом active.
Если в вашей системе (ах) есть миллионы запросов, у SELECT whatever FROM T_OLD WHERE whateverвас есть два варианта развертывания:
1) Холодная Турция - измените БД, и в то же время измените, протестируйте и выпустите многочисленные фрагменты кода, содержащие указанный запрос. ОЧЕНЬ сложно сделать (или даже скоординировать), очень рискованно. Плохой.
2) Постепенное - изменение БД, создав T_NEWтаблицу, опуская T_OLDтаблицу и вместо того, чтобы создать VIEW под названием , T_OLDчто имитирует T_OLDтаблицу 100% (например , вид запроса SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Это позволит вам избежать выпускать любой код , который в настоящее время выбирает из T_OLD, и сделать изменения мигрировать код из T_OLDк T_NEWна досуге.
Это простой пример, есть и другие, гораздо более сложные.
PS С другой стороны, вам, вероятно, следовало бы иметь API хранимых процедур вместо прямых запросов из T_OLD, но это не всегда так.
(Скопировано из первого руководства, появившегося в поиске Google (ссылка теперь мертва), но в нем есть все преимущества, которые я бы сам набрал вручную.)
Просмотры имеют следующие преимущества:
- Безопасность - представления можно сделать доступными для пользователей, в то время как базовые таблицы недоступны напрямую. Это позволяет администратору баз данных предоставлять пользователям только те данные, которые им нужны, одновременно защищая другие данные в той же таблице.
- Простота - представления можно использовать для скрытия и повторного использования сложных запросов.
- Упрощение или уточнение имени столбца - представления могут использоваться для предоставления псевдонимов имен столбцов, чтобы сделать их более запоминающимися и / или значимыми.
- Ступенька - представления могут стать отправной точкой в «многоуровневом» запросе. Например, вы можете создать представление запроса, в котором подсчитывается количество продаж, совершенных каждым продавцом. Затем вы можете запросить это представление, чтобы сгруппировать продавцов по количеству произведенных ими продаж.
Некоторые причины из Википедии :
Представления могут иметь преимущества перед таблицами:
VIEWS могут использоваться как повторно используемые разделы SELECT / CODE, которые могут быть включены в другие выборки / запросы, к которым нужно присоединиться, и использовать различные различные фильтры, без необходимости заново создавать весь SELECT каждый раз.
Это также размещает логику в одном месте, так что вам не нужно менять ее во всей базе кода.
Посмотри на
Выбор между хранимыми процедурами, функциями, представлениями, триггерами, встроенным SQL
Основная прелесть представления в том, что его можно использовать как таблицу в большинстве ситуаций, но, в отличие от таблицы, оно может инкапсулировать очень сложные вычисления и часто используемые объединения. Он также может использовать практически любой объект в базе данных, кроме хранимых процедур. Представления наиболее полезны, когда вам всегда нужно присоединиться к одному и тому же набору таблиц, например, заказ с подробностями заказа, чтобы получить поля итогового расчета и т. Д.
Представление - это уровень абстракции, и он выполняет то же самое, что и любой хороший уровень абстракции, включая инкапсуляцию схемы базы данных и защиту вас от последствий изменения внутренних деталей реализации.
Это интерфейс.
Вот один из очень распространенных способов использования представлений для ограничения сущности некоторыми критериями.
Таблица: USERS содержит всех пользователей
Представление: ACTIVE_USERS содержит всех пользователей, за исключением тех, которые заблокированы, заблокированы, ожидают активации и не соответствуют каким-либо критериям, которые вы можете определить в будущем как часть активных требований. Это избавляет от необходимости удалять какие-либо строки из таблицы USERS, если вы решите этого не делать, потому что ACTIVE_USERS всегда может скрыть ненужные строки.
Таким образом, вы можете использовать таблицу на своих страницах управления пользователями, но остальная часть приложения может использовать ACTIVE_USERS, поскольку они могут быть единственными пользователями, которые должны иметь возможность выполнять процессы и получать доступ / изменять данные.
Представления могут позволить вам объединять данные из нескольких разных таблиц и форматировать их (объединять поля, давать более понятные имена полей и т. Д.), Чтобы это было проще для конечных пользователей. Они являются абстракцией модели базы данных. Их также можно использовать для предоставления пользователям доступа к данным в таблице, не давая им прямого доступа к самой таблице.
Вот некоторые из многих причин использования представления, а не таблицы напрямую
Взгляды злы! По возможности избегайте их и используйте только по указанной DVK причине - временная миграция данных.
Вы должны понимать, что в базе данных со 100 таблицами трудно запомнить назначение каждой таблицы. Теперь, если вы добавите сюда еще 300 просмотров, это станет полным беспорядком. «Любители представлений» склонны использовать вложенные представления, а затем использовать вложенные представления в хранимых процедурах. Сейчас я лично работаю с базой данных, в которой 4 раза глубоко вложены просмотры! Итак, чтобы понять простейшую логику хранимой процедуры, мне нужно сначала просмотреть все представления.