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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

В additition к уже упоминалось преимущества:

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

Я хотел бы отметить:

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