Одним из самых больших преимуществ использования материализованного представления является то, что Oracle заботится о синхронизации данных. Если у вас есть отдельная сводная таблица, вы несете ответственность за синхронизацию данных. Как правило, для этого требуется разумное количество кода и приличное количество тестирования, и большинству организаций удается совершать ошибки, которые оставляют дыры, которые приводят к потере синхронизации сводной таблицы. Это особенно верно, когда вы пытаетесь реализовать инкрементные обновления сводной таблицы.
Другое важное преимущество заключается в том, что в зависимости от настроек Oracle может использовать перезапись запросов для использования материализованных представлений, когда пользователи выдают запросы к базовым таблицам. Так, например, если у вас есть куча существующих отчетов по детальной таблице, которые производят ежедневные, ежемесячные и годовые сводные результаты, вы можете создать материализованное представление на базовой таблице, которое агрегирует данные на ежедневном уровне, и оптимизатор может использовать это материализованное представление для всех ваших существующих запросов. Это значительно упрощает оптимизацию рабочих нагрузок отчетов в хранилище данных, не пытаясь переписать десятки отчетов, чтобы использовать новую сводную таблицу или связываться с ней, DBMS_ADVANCED_REWRITE
чтобы заставить вас самостоятельно переписывать запросы.
ON DEMAND
это стандартное поведение обновления. Материализованное представление должно быть создано с помощьюON COMMIT
. и поддержание материализованного представления не является бесплатным. Это, вероятно, дешевле, чем триггер.Хорошим примером использования MV является то, что иногда вам нужно объединять данные и получать эту сводную информацию из больших таблиц часто и быстро. Без материализованных представлений вам придется либо деонормировать некоторые из ваших таблиц и поддерживать агрегаты с помощью кода, либо повторно сканировать большие наборы строк. В любом случае это не всегда приемлемо, особенно с приборной панелью и аналогичными онлайн-приложениями. Если вы храните результаты в отдельных таблицах, вы усложняете код приложения и, как говорит @Justin Cave, вы будете следить за синхронизацией данных, собранных вручную. с данными исходной таблицы.
источник
Не человек Oracle, но другой вариант использования будет сторонних решений. Как правило, они не поддерживают внесение изменений в их проекты, но MV будет «невидимым» для их кода, но обеспечит доступ к настраиваемым отчетам / экстрактам данных.
Это не бесплатно в том смысле, что это будет стоить затрат на хранение и потенциально значительных затрат времени на вставку / обновление, но это может быть компенсировано временем, затраченным на получение материализованных данных, по сравнению с «прямым просмотром» или созданием реальных таблиц и поддержанием окружающего ETL.
Наконец, это может привести к расторжению вашего контракта на поддержку с поставщиком, обратитесь к вашему юристу-бла-бла-бла
источник
Вместо того, чтобы переходить непосредственно к материализованным представлениям, позвольте мне объяснить представления .
В основном представления существуют логически в отличие от таблиц. Если мы хотим скрыть определенные столбцы для пользователей, мы не можем использовать таблицы. Создавая представление, мы можем добиться безопасности.
Вариант использования: если представление внутренне связано с 10 таблицами вместе с группировкой, а функции имеют миллионы строк, выполнение занимает много времени.
Итак, вот материализованные представления помогают нам быстрее получать данные. Материализованные представления физически существуют в базе данных. Всякий раз, когда обновляется базовая таблица, обновляется материализованное представление.
источник
Материализованное представление может быть настроено на автоматическое обновление на периодической основе. Для таблицы может потребоваться дополнительный код для усечения / перезагрузки данных.
пример: материализованное представление, содержащее данные из нескольких таблиц, может быть настроено на автоматическое обновление в непиковые часы. Физической таблице потребуется дополнительный код для усечения / перезагрузки данных.
Безопасность можно лучше контролировать в материализованном виде, а не в таблице.
источник
Материализованное представление - это объект базы данных, который содержит результаты запроса. Они являются локальными копиями данных, расположенными удаленно, или используются для создания сводных таблиц на основе совокупности данных таблицы. http://www.oraappdata.com/2016/04/materialized-view.html
источник