通常，我会考虑用于报告用户的视图层或物化视图层。除非存在具体的性能问题，否则我的偏好是使用视图来创建偶尔使用查询重写来加速所选报表的物化视图。
如果您使用物化视图，您显然会第二次实现数据，但格式会导致存储效率降低。这意味着系统中的大部分空间将分配给非规范化的物化视图及其索引。这可能会从您的磁盘供应商那里产生相当大的费用，并且可能会产生对SAN资源的争用。
物化视图还意味着OLTP与报告用户之间的缓存空间竞争更加激烈。由于它们存储在不同的对象中，因此查找最近活动的报告将无法从OLTP活动中的缓存中的热块中受益，反之亦然。您可以通过向其投放RAM或将报告移至非高峰时间来缓解此问题，但这不是最有效的解决方案。如果您几乎完全是历史报告，这可能不是什么大不了的事情 - 无论如何都不会分享，因为流程对完全不同的块感兴趣 - 但如果您有大量的操作报告，那么它就变得非常重要。
物化视图也可能不太灵活。如果您想以多种方式呈现相同的数据，那么多次实现它会在磁盘和缓存中产生实际成本，并增加定期刷新物化视图层所需的时间。实际上，这往往意味着报告用户获得数据的最小公分度视图，并且在切片和切块数据时必须重新发明轮子，因为IT不想为它们创建新的物化视图。
正如我之前所说，我的偏好是常规视图层。这样可以避免多次存储数据的成本，并且可以在OLTP和报告查询之间共享缓存中的块。它还使得为用户提供不同的数据视图变得相对容易，并且无需让业务用户了解他们报告的数据的陈旧程度。如果性能成为问题，因为OLTP数据模型不支持您要运行的各种查询，则可以创建目标物化视图，其作用类似于索引
查询重写
。这意味着用户可以查询常规视图，DBA可以稍后添加生成全部或部分结果的物化视图，优化器可以更改查询计划以使用新的物化视图，而不是扫描表和操作比如在运行时聚合数据。
在某些时候，您可能希望将报告流量移动到具有更多维度数据模型的真实数据仓库。如果您发现确实需要物化视图层而不是常规视图层的性能，我会强烈考虑使用事实和维度进入真正的数据仓库。您将获得更灵活的报告功能，基本上与您使用完整的物化视图层可能获得的ETL头痛相同。