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