Когда действительно следует использовать View поверх реальной таблицы? Какие выгоды я должен ожидать от этого?
В целом, каковы преимущества использования представления над таблицей? Разве я не должен спроектировать таблицу так, как в первую очередь должно выглядеть представление?
Ответы:
О, есть много различий, которые вам нужно учитывать
Просмотры на выбор:
Просмотры для вставки / обновления:
Недостатки
Просмотры могут:
И вы не должны создавать таблицы, соответствующие представлениям . Ваша базовая модель должна заботиться об эффективном хранении и извлечении данных. Представления - это отчасти инструмент, который смягчает сложности, возникающие из-за эффективной нормализованной модели, позволяя абстрагироваться от этой сложности.
Кроме того, вопрос «Каковы преимущества использования представления над таблицей?» - не лучшее сравнение. Без таблиц не обойтись, но можно и без представлений. Каждый из них существует по разным причинам. Таблицы - это конкретная модель, а представления - это абстрактное представление.
Представления приемлемы, когда вам нужно убедиться, что каждый раз соблюдается сложная логика. Например, у нас есть представление, которое создает необработанные данные, необходимые для всей финансовой отчетности. Если все отчеты используют это представление, все работают с одним и тем же набором данных, а не с одним отчетом, использующим один набор объединений, а другой забывает использовать тот, который дает разные результаты.
Представления приемлемы, если вы хотите ограничить пользователей определенным набором данных. Например, если вы не удаляете записи, а только помечаете текущую как активную, а более старые версии как неактивные, вы хотите, чтобы представление использовалось для выбора только активных записей. Это предохраняет людей от того, чтобы забыть поместить предложение where в запрос и получить плохие результаты.
Представления могут использоваться, чтобы гарантировать, что пользователи имеют доступ только к набору записей - например, представление таблиц для конкретного клиента и отсутствие прав безопасности для таблиц может означать, что пользователи для этого клиента могут когда-либо видеть только данные для этого клиента.
Представления очень полезны при рефакторинге баз данных.
Представления неприемлемы, когда вы используете представления для вызова представлений, что может привести к ужасной производительности (по крайней мере, в SQL Server). Мы почти потеряли многомиллионного клиента из-за того, что кто-то решил абстрагироваться от базы данных таким образом, и производительность была ужасной, а таймауты частыми. Нам тоже пришлось заплатить за исправление, а не за клиента, поскольку проблема с производительностью была полностью нашей ошибкой. Когда представления вызывают представления, они должны полностью генерировать базовое представление. Я видел это, когда представление вызывало представление, которое вызывало представление, и было сгенерировано столько миллионов записей, чтобы увидеть три, которые в конечном итоге понадобились пользователю. Я помню, что одному из этих представлений потребовалось 8 минут, чтобы произвести простой подсчет (*) записей. Представления, вызывающие представления - крайне плохая идея.
Представления часто являются плохой идеей для обновления записей, поскольку обычно вы можете обновлять только поля из той же таблицы (опять же, это SQL Server, другие базы данных могут отличаться). В этом случае имеет смысл в любом случае напрямую обновлять таблицы, чтобы вы знали, какие поля доступны.
Представления удобны, когда вам нужно выбрать из нескольких таблиц или просто получить подмножество таблицы.
Вы должны проектировать свои таблицы таким образом, чтобы ваша база данных была хорошо нормализована (минимальное дублирование). Это может затруднить выполнение запросов.
Представления - это небольшое разделение, позволяющее просматривать данные в таблицах иначе, чем они хранятся.
Распространенной практикой является скрытие объединений в представлении, чтобы предоставить пользователю более денормализованную модель данных. Другие варианты использования включают безопасность (например, путем скрытия определенных столбцов и / или строк) или производительность (в случае материализованных представлений).
Вы должны проектировать свою таблицу БЕЗ взглядов.
Помимо сохранения соединений и условий, представления имеют преимущество в производительности: SQL Server может вычислять и сохранять свой план выполнения в представлении и, следовательно, делать его быстрее, чем операторы SQL «на лету».
Просмотр также может облегчить вашу работу по доступу пользователей на полевом уровне.
Прежде всего, как следует из названия, представление неизменяемо. это потому, что представление - это не что иное, как виртуальная таблица, созданная из сохраненного запроса в БД. Из-за этого у вас есть некоторые характеристики просмотров:
Таким образом, существует множество вариантов использования, для которых представления лучше подходят, чем таблицы, просто подумайте об отображении только активных пользователей на веб-сайте. представление было бы лучше, потому что вы работаете только с подмножеством данных, которые фактически находятся в вашей БД (активные и неактивные пользователи)
проверьте эту статью
надеюсь, что это помогло ..
Согласно Википедии ,
Представления могут ограничивать степень раскрытия базовых таблиц внешнему миру: у данного пользователя может быть разрешение на запрос представления, но ему может быть отказано в доступе к остальной части базовой таблицы.
Представления могут объединять и упрощать несколько таблиц в одну виртуальную таблицу.
Представления могут действовать как агрегированные таблицы , в которых ядро базы данных агрегирует данные (сумму, среднее значение и т. Д.) И представляет вычисленные результаты как часть данных.
Представления могут скрыть сложность данных. Например, представление может отображаться как Sales2000 или Sales2001, прозрачно разделяя фактическую базовую таблицу.
Представления занимают очень мало места для хранения ; база данных содержит только определение представления, а не копию всех данных, которые он представляет.
Представления могут обеспечить дополнительную безопасность в зависимости от используемого механизма SQL.