SQL Server - 生产数据库架构与报告数据库架构。它们应该是一样的吗？

Question

我们最近使用了一个新的生产数据库。此数据库的架构针对OLTP进行了优化。我们还准备实施报告服务器以用于报告目的。我不相信我们应该盲目地为我们的报告数据库使用与生产数据库相同的模式，并复制数据。

对于那些处理过具有单独的生产和报告数据库的人，您是否选择为报告数据库使用相同的数据库模式，或者使用更有效的报告模式;例如，也许更正规化的东西？

感谢您对此的想法。

Answer 1

这个故事真的有两个方面：

• 如果保持架构相同，则从生产中更新报表数据库是一个简单的副本（或SQL Server 2008中的MERGE）命令。另一方面，报告可能会更难写，并且可能无法以最佳方式执行

• 如果您设计单独的报告模式，则可以根据报告需求进行优化 - 然后创建新报告可能会更容易，更快，报告应该会更好。但是：更新会更难

所以它真的归结为：你打算制作大量的报道吗？如果是这样的话：我建议您提供针对报告优化的特定报告模式。

升级是主要的痛点吗？如果您可以定义并实现一次（例如，使用SQL Server Integration Services），那么这可能不会成为一个大问题吗？

通常情况下，您可能会创建大量时间报告，因此从长远来看，在单独的报告模式和数据加载过程中预先进行投资可能是有益的。通常使用SSIS），然后获得更好的报告和更快的报告创建时间的好处。

Answer 2

我认为应该针对报告优化报告数据库模式 - 因此您需要ETL过程来加载数据。根据我的经验，我很快就发现生产模式不符合我的报告需求。

如果您要开始报告项目，我建议您根据报告需求设计报告数据库。

Answer 3

对于严肃的报告，通常您创建数据仓库（通常至少在某种程度上非规范化，并且在刷新数据时执行某些类型的计算，以便在运行报告时平均130万条记录的值。这是对于那种包含大量汇总数据的报告报告。

如果您的报告需求不是那么好，则复制的数据库可能会起作用。它可能还取决于您需要数据的最新状态，因为数据仓库通常每天更新一次或两次，因此报告数据通常会落后一天，对于月度和季度报告来说还不错今天到目前为止已订购了许多widgits。

确定您是否需要数据仓库往往会花费多长时间来查看他们需要的报告。这就是数据仓库预加载数据的原因。如果您的reoports运行正常并且您只是希望远离输入工作负载，则复制的数据库应该可以解决问题。如果您尝试对过去十年的所有记录进行数学运算，则需要一个数据仓库。

您也可以按步骤执行此操作。立即进行复制，以便远离数据输入进行报告。这应该是一个立即的改进（即使没有你想要的那么多），然后设计和实现数据仓库（这可能是一个相当长的涉及项目，并且需要一些时间才能正确）。

Answer 4

最容易复制。

您可以向该架构添加一些视图以简化查询 - 从概念上非规范化。

如果您想要完整的数据仓库/分析服务路线，那将是相当多的工作。但它速度非常快，占用的空间更少，用户似乎更喜欢它。如果你担心大量的数据和响应时间，你应该研究一下。

如果您要连接许多表，您可能会考虑实际对数据进行非规范化。我会做一个测试案例，看看你将获得多少痛苦。

Answer 5

如果不直接使用数据仓库解决方案，您可以随时整理一些重新排列数据的视图，以获得更好的报告访问权限。这有助于您不必立即启动大型仓库项目，如果您决定采用这种方式，可以帮助确定仓库项目的范围。

Answer 6

我在这里读到的所有答案都很好，我只想补充一点，分阶段执行此操作，一旦达到性能和功能目标就停止：

保持架构相同 - 这只是争用并加载OLTP服务器

保持架构相同 - 但以不同方式添加新的索引视图或索引基表

从同一报表服务器上的另一个架构或数据库中的复制架构构建部分数据仓库样式模型（可能不保留快照样式历史记录或缓慢更改维度或正常数据库中未满足的任何特殊情况）。星型模式模型的好处对于报告来说是巨大的，对于用户和数据字典来说是扁平化的视图等。在此模型中，如果OLTP数据库因覆盖而丢失更改（例如客户名称更改），则数据仓库不会捕获信息（如果你停在这个地方，通常并不重要）。实际上，您只能获得“当前”数据的数据仓库式组织。此时保留原始模式副本在报表服务器上的好处是，您可以从原始SQL Server表单中的源数据而不是某种中间形式（如文本文件）中提取而不影响生产OLTP，并且您可以逐步迁移数据模型，一些是星星，一些是正常形式，都不会影响生产。稍后，您可以删除全部或部分副本。

构建一个完整的数据仓库，包括从源系统捕获所有数据的缓慢变化的维度。