Материализованный взгляд на таблицы: каковы преимущества?

Мне ясно, почему материализованное представление предпочтительнее простого запроса базовой таблицы. То, что не так ясно, - это преимущество перед созданием другой таблицы с теми же данными, что и MV. Является ли единственным преимуществом для MV просто простота создания/обслуживания?

Разве MV не эквивалентен таблице с соответствующей схемой и INSERT INTO с использованием оператора MVS SELECT?

Значение, вы можете создать MV следующим образом

CREATE MATERIALIZED VIEW ... AS
SELECT * FROM FOO;

И вы можете создать эквивалентную таблицу:

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

В дополнение к уже упомянутым преимуществам:

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

Я хотел бы упомянуть:

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