Когда использовать представление вместо таблицы?


когда представление должно фактически использоваться над фактической таблицей? Какие выгоды я должен ожидать от этого?

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

8 91

8 ответов:

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

вид на выбор:

  1. представления обеспечивают абстракцию над таблицами. Вы можете легко добавлять/удалять поля в представлении без изменения базовой схемы
  2. представления могут моделировать сложные соединения легко.
  3. представления могут скрывать от вас информацию, относящуюся к базе данных. Например, если вам нужно сделать некоторые проверки с помощью функции Oracles SYS_CONTEXT или многих других вещей
  4. вы вы можете легко управлять своими грантами непосредственно в представлениях, а не в фактических таблицах. Это легче управлять, если вы знаете, что определенный пользователь может получить доступ только к представлению.
  5. представления могут помочь вам с обратной совместимостью. Вы можете изменить базовую схему, но взгляды могут скрыть эти факты от определенного клиента.

вид для вставки/обновления:

  1. вы можете справиться с проблемами безопасности с представлениями, используя такие функции, как Oracle " WITH Проверьте опцию " предложение непосредственно в представлении

недостатки

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

вид:

  • упростить сложную структуру таблицы
  • упростите свою модель безопасности, позволяя фильтровать конфиденциальные данные и назначать разрешения более простым способом
  • позволяет изменять логику и поведение без изменения структуры вывода (вывод остается прежним, но базовый выбор может значительно измениться)
  • повышение производительности (индексированные представления Sql Server)
  • предложение конкретного запроса оптимизация с точки зрения, что может быть трудно собрать в противном случае

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

кроме того, спрашивая: "каковы преимущества использования за столом? "не отличное сравнение. Вы не можете обойтись без таблиц, но вы можете обойтись без представлений. Каждый из них существует по совершенно другой причине. Таблицы-это конкретная модель, а представления-абстрактное, ну, представление.

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

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

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

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

представления неприемлемы, когда вы используете представления для вызова представлений, которые могут привести к ужасной производительности (по крайней мере, в SQL Server). Мы почти потеряли многомиллионного клиента, потому что кто-то решил абстрагировать базу данных таким образом, и производительность была ужасной, а тайм-ауты частыми. Мы должны были заплатить за исправление тоже, а не клиент, так как проблема производительности была полностью нашей ошибка. Когда представления вызывают представления, они должны полностью генерировать базовое представление. Я видел это, когда представление называлось представлением, которое называлось представлением, и было создано так много миллионов записей, чтобы увидеть три, которые в конечном итоге нужны пользователю. Я помню, что один из этих видов занял 8 минут, чтобы сделать простой подсчет(*) записей. Представления вызов представлений-это очень плохая идея.

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

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

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

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

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

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

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

  • вы можете показать только подмножество данных
  • вы можете объединить несколько таблиц в одно представление
  • вы можете агрегировать данные в представлении (выберите count)
  • просмотр на самом деле не содержит данных, им не нужны табличные пространства, так как они являются виртуальными агрегациями базовых таблиц

таким образом, существует множество вариантов использования, для которых представления лучше подходят, чем таблицы, просто подумайте о том, чтобы отображать только активных пользователей на веб-сайте. представление было бы лучше, потому что вы работаете только с подмножеством данных, которые фактически находятся в вашей БД (активные и неактивные пользователи)

зацените статьи

надеюсь, что это помогло..

по данным Википедия,

представления могут обеспечить много преимуществ над таблицами:

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

  • представления могут объединять и упрощать несколько таблиц в одну виртуальную таблицу.

  • представления могут выступать в качестве обобщенных таблиц, где компонент database engine агрегирует данные (sum, average и др.) и представляет вычисленные результаты как часть данных.

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

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

  • просмотры могут обеспечить дополнительную безопасность в зависимости от используемого SQL-движок.