SQL Server-用于报告的单独数据库？

在我们的SQL Server上，我们为每个Web应用程序都有一个数据库。对于报表，我们使用Reporting Services，所有报表数据（包括报表参数）均来自存储过程。

存储过程与报告中的数据位于同一数据库中。因此，例如，为“库存”报告提供服务的proc在“库存”数据库中。一些报告显示来自多个数据库的信息，然后proc将位于那些源数据库之一中。报表参数从企业数据库（包含商店，员工等数据）的proc中获取其数据。

这意味着所有报告至少都具有与Enterprise数据库的连接，以及与另一个数据库的另一个连接-有时甚至更多。

我的问题是：将报告过程移入单独的“报告”数据库是否有好处？我知道将报表移到另一台服务器上的好处，我不是在谈论它-这将在同一台服务器上。

可能影响此的因素是：

• 一个报告具有多个数据库连接是否会影响报告的速度？
• 将报表proc与数据保存在单独的数据库中是否会阻止我们使用索引视图？
• 您是否发现在单独的数据库中管理报告更容易/更困难？

请让我知道你的想法。

答案是：是的，这样做有好处。关于操作数据库的报告将使用大量资源，并且会干扰操作系统的性能。请记住，数据库性能受机械约束（磁盘磁头来回移动和旋转延迟，因为我们等待正确的扇区在磁头下出现）。报告策略有两种主要选择：

1. 将数据库复制到另一台服务器上，然后将报告存储移到该服务器上。报表在复制的服务器上运行。这是最少的工作，可以重用您现有的报告和存储过程。
2. 建立一个数据仓库，合并来自生产系统的数据，并将其转换为更易于报告的形式。如果您有很多临时统计报告，可以从快照（“昨天停业”）进行可接受的处理，那么数据仓库可能是更好的方法。

我认为这很大程度上取决于您正在运行的SP的类型。如果它们很重并且可能影响数据库服务器上运行的其他内容，则将其移动。否则，如果发现这样更易于维护和跟踪，我将尽量保持与他们实际报告的数据库接近。仅使报告接近实际数据库也可能会影响性能，但是如果您使用标准设置并且不移动大量数据，我猜这将是一个很小的差异。

我也发现这篇文章很有用。

由于多种原因，我建议不要将存储过程移至另一个数据库。从开发角度看，每次要进行更改时，都必须重现两个数据库。因此，您现在将如何将“数据”数据库中的模式与第二个数据库中的存储过程与生产版本进行同步。关于灾难恢复和备份/还原，您现在必须关心恢复2个数据库，以使您的系统正常运行。

在测试时，您还增加了复杂性。您将在权限，版本等方面遇到更多的故障点。现在，如果您有1个以上的人员从事数据库的不同计划，那么您将有更多的时间花费在协调工作上。现在想象一下它的凌晨3点，系统已关闭，您必须搜寻所有数据库的权限，并且必须确保在开发过程中没有人在错误的数据库上留下任何功能或过程。

我建议您使用两个数据库。

从“实时”数据库导出报告会导致性能问题。

另外，由于报告数据库主要用于搜索，因此您可以在此处自定义索引以提高性能。（实时数据库将具有某些索引可能会对插入产生不利影响的插入）

另一种方法是将报告表移动到单独的方案和单独的文件组。报告文件组中的文件可以从数据硬盘上移开。这对于管理，将来的开发和访问管理来说更加容易。