我们最近使用了一个新的生产数据库。此数据库的模式针对 OLTP 进行了优化。我们还准备实施用于报告目的的报告服务器。我不相信我们应该盲目地为我们的报告数据库使用与我们为生产数据库所做的相同的模式，并复制数据。
对于那些处理过拥有单独的生产和报告数据库的人，您是否选择为您的报告数据库使用相同的数据库架构，或者使用更高效的报告架构？例如，也许更非规范化的东西？
感谢您对此的想法。
【问题讨论】：
标签： sql-server reporting
这个故事真的有两个方面：
如果您保持架构相同，则从生产中更新报告数据库是一个简单的复制（或 SQL Server 2008 中的 MERGE）命令。另一方面，报告可能会变得更难编写，并且可能无法达到最佳效果
如果您设计了一个单独的报告架构，则可以针对报告需求对其进行优化 - 那么新报告的创建可能会更容易、更快，并且报告的性能应该会更好。但是：更新会更难
所以归根结底是：您要创建大量报告吗？如果是这样：我建议提出针对报告优化的特定报告架构。
还是升级的主要痛点？如果您可以定义并实现一次（例如使用 SQL Server 集成服务），那么这可能就不会成为一个大问题了？
通常情况下，您可能会创建大量时间报告，因此从长远来看，在单独的报告架构和数据加载过程中预先投入一些资金很有可能是有益的（通常使用 SSIS），然后获得性能更好的报告和更快的报告创建时间的好处。
【讨论】：
我认为报告数据库架构应该针对报告进行优化 - 因此您需要一个 ETL 流程来加载您的数据。根据我的经验，我很快就发现生产模式不适合我的报告需求。
如果您正在开始您的报告项目，我建议您根据报告需求设计报告数据库。
【讨论】：
对于严肃的报告，通常您会创建数据仓库（通常至少在某种程度上是非规范化的，并且在刷新数据以保存运行报告时 130 万条记录的平均值时会完成某些类型的计算。这是适用于包含大量汇总数据的报告报告。
如果您的报告需求不是那么大，复制数据库可能会起作用。它还可能取决于您需要数据的最新程度，因为数据仓库通常每天更新一次或两次，因此报告数据通常落后一天，对于月度和季度报告来说还可以今天到目前为止已经订购了许多widgits。
您是否需要数据仓库的决定因素往往是运行所需的报告需要多长时间。这就是数据仓库在加载数据时预先聚合数据的原因。如果您的报告运行良好，并且您只想让工作负载远离输入工作负载，那么复制的数据库应该可以解决问题。如果您想对过去十年的所有记录进行数学运算，您需要一个数据仓库。
您也可以分步执行此操作。现在进行复制，以使报告远离数据输入。这应该是一个立竿见影的改进（即使不是你想要的那么多），然后设计和实施数据仓库（这可能是一个相当长且涉及的项目，并且需要一些时间才能做好）。
【讨论】：
复制过来最简单。
您可以向该架构添加一些视图以简化查询 - 从概念上进行非规范化。
如果您想走完整的数据仓库/分析服务路线，那将是相当多的工作。但它非常快，占用空间少，用户似乎喜欢它。如果您担心大量数据和响应时间，您应该研究一下。
如果您要连接许多表，您可能会考虑实际对数据进行非规范化处理。我会做一个测试用例，看看你会从痛苦中获得多少收益。
【讨论】：
如果不直接使用数据仓库解决方案，您总是可以将一些视图放在一起，重新排列数据以获得更好的报告访问。这有助于您不必立即开始一个大型仓库项目，并且如果您决定这样做，可以帮助您确定一个仓库项目的范围。
【讨论】：
我在这里阅读的所有答案都很好，我只想补充一点，您分阶段执行此操作，一旦达到您的性能和功能目标就停止：
保持架构相同 - 这只是竞争并从 OLTP 服务器上加载
保持架构相同 - 但添加新的索引视图或索引基表不同
从同一报告服务器上另一个架构或数据库中的副本架构构建部分数据仓库样式模型（可能不保留快照样式历史记录或缓慢变化的维度或正常数据库中未满足的任何特殊内容）。星型模式模型的好处对于报告、为用户扁平化的视图和数据字典等而言是巨大的。在此模型中，如果您的 OLTP 数据库由于覆盖而丢失更改（例如客户名称更改），则数据仓库不会捕获该信息（如果你停在这个地方，通常它并不那么重要）。实际上，您获得的只是“当前”数据的数据仓库式组织。此时在报告服务器上保留原始架构副本的好处是，您可以从原始 SQL Server 形式而不是某种中间形式（如文本文件）中提取源数据，而不会影响生产 OLTP，并且您可以逐步迁移数据模型，有的是star，有的是normal，都不会影响生产。稍后，您也许可以删除全部或部分副本。
构建一个完整的数据仓库，包括从源系统捕获所有数据的缓慢变化的维度。
【讨论】：