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