Материализованное представление по сравнению с таблицами: в чем преимущества?

Динамическое перезапись запросов. Материализованные представления определяют не только отношения, но также позволяют предварительно вычислять дорогостоящие объединения и агрегации. Оптимизатор достаточно умен, чтобы использовать MV для извлечения релевантных данных, даже если MV явно не используется в запросе (с учетом настроек БД и т. Д.).

Ваш вопрос был помечен как Oracle, но MSSQL также делает аналогичные трюки.

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

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

Ваше второе утверждение - это всего лишь одноразовая сделка - в этот момент данные вставляются в таблицу. Дальнейшие изменения исходных данных в таблице не отражаются.

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

1. Материализованное представление останется синхронизированным с базовыми отношениями, от которых оно зависит.

2. Если материализованное представление является обновляемым, при изменении материализованного представления оно также изменит базовое отношение, от которого оно зависит.

Помимо уже упомянутых преимуществ:

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

Хочу отметить:

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

Думаю, правильным сравнением было бы:

REFRESH MATERIALIZED VIEW bar;

против:

CREATE TABLE bar (....);
INSERT INTO bar 
SELECT * FROM FOO;

Поскольку MV вы можете сделать это один раз и обновить, когда вам нужно сделать выбор (и даже сэкономить несколько вызовов, если вы знаете, как часто изменяется информация)

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

В postgres вы также можете сделать это:

REFRESH MATERIALIZED VIEW CONCURRENTLY bar;

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

Это то, что вы не можете сделать с помощью SELECT INSERT INTO.

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

1) Ускорение операций записи: поскольку индексы могут быть созданы на материализованных представлениях, чтение из них происходит очень быстро. Обратите внимание, что если вы создаете индекс для таблицы, которая включает много операций записи, накладные расходы на обслуживание индекса имеют тенденцию замедлять процесс записи. Чтобы избежать этого, вы можете создать материализованное представление и создать для них индексы. Эти индексы могут поддерживаться в фоновом режиме и не влияют отрицательно на операции записи в таблицу.

2) Ускорение операций чтения: сложные соединения; сводные таблицы, выполнение которых требует времени, можно ускорить, создав индексы для материализованных представлений. Это становится очень удобным в большинстве сценариев отчетности.

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

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

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

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