我认为报表数据库架构应该针对报表进行优化 - 因此，您需要一个ETL过程来加载您的数据。根据我的经验，我很快就发现生产数据库架构无法满足我的报表需求。
如果您正在启动报表项目，我建议您根据报表需求设计报表数据库。
对于严肃的报告，通常你需要创建数据仓库（这通常是至少有点非规范化的，并在刷新数据时进行某些类型的计算，以避免在运行报告时平均1.3万条记录的值。这适用于包括大量汇总数据的报告。
如果你的报表需求不是那么大，复制的数据库可能会起作用。这也可能取决于你需要多新的数据，因为数据仓库通常每天更新一到两次，因此报告数据通常落后一天，适用于月度和季度报告，但不适合查看今天已经订购了多少小部件。
是否需要数据仓库的确定通常取决于运行所需报告的时间。这就是为什么数据仓库在加载数据时预先聚合数据。如果你的报告运行正常，只想将工作负载从输入工作负载中剥离出来，那么复制的数据库应该可以解决问题。如果你试图在过去十年所有记录上进行数学计算，你需要一个数据仓库。
你也可以分步进行。现在进行复制，以使报告远离数据输入。这应该是一个立即的改进（即使不如你想要的那么多），然后设计和实施数据仓库（这可能是一个相当长和复杂的项目，并且需要一些时间才能做到正确）。
最简单的方法就是复制过去。
您可以向该模式添加一些视图以简化查询-概念上进行非规范化处理。
如果您想要完整的数据仓库/分析服务路线，那么需要做很多工作。但它非常快速，占用空间较少，用户似乎很喜欢。如果您担心大量数据和响应时间，您应该研究一下这个。
如果您有许多表被连接，您可能需要实际上对数据进行非规范化处理。我会进行一个测试案例，以查看您将获得多少收益。
如果不直接使用数据仓库解决方案，您可以始终组合一些视图以重新排列数据，从而更好地访问报告。这有助于您，因为您不必立即开始一个大型仓库项目，并且可以帮助确定是否需要进行仓库项目。
建立一个部分数据仓库风格的模型（可能不保留快照式历史记录、慢变化维度或任何在您正常数据库中未提供特殊支持的内容），从同一报告服务器上的另一个模式或数据库的复制模式中构建。星型模式对于报告、为用户展开的视图和数据字典等方面有巨大的好处。在这个模型中，如果您的 OLTP 数据库由于覆盖而丢失更改（例如客户名称更改），则数据仓库不会捕获该信息（通常在此处停止并不重要）。实际上，您只能获取“当前”数据的数据仓库风格组织。在此时保留原始模式的副本在您的报告服务器上的好处是，您可以从原始 SQL Server 形式的源数据中提取，而不会影响生产 OLTP，并且您可以逐步迁移数据模型，一些是星形，一些是正常形式，所有这些都不会影响生产。稍后，在某个时间点，您可能能够删除全部或部分副本。
建立一个完整的数据仓库，包括慢变化维度，其中所有数据都来自源系统。
