Индексированные представления в OLTP?

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

Сложный баланс заключается в том, насколько свежими должны быть данные для отчетов, и тем, какое влияние вы можете оказать на производительность OLTP. Если несколько устаревшие данные в порядке, вы можете запланировать обновления представлений в то время, когда активность системы низкая.

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

К сожалению, его было сложно поддерживать, и в нем не использовались простые встроенные инструменты. Если вы можете подождать с данными отчетов, часто лучше использовать встроенные материализованные представления и отложить обновление.

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