我正在征求有关报告解决方案的建议
我们开发了很多内部项目（.net 和 sql server）。对于更大的数据库，我们使用业务对象并为报告构建 Universe，以便分析师或报告编写者可以构建报告，而无需开发人员参与。
我们的许多项目都包含重要数据，但还不够大，无法保证在这些数据上构建的 Universe 和数据仓库。我们仍然需要根据这些数据构建报告，但我们不想报告实时数据库，因为这可能会影响应用程序的性能。对于我们的一些项目，我们每晚进行备份/恢复，有效地复制数据库，然后将副本用作报告数据库。没有很多报告经验，我想知道人们实施了哪些其他解决方案。
【问题讨论】：
标签： sql-server reporting
在这种情况下，我们已将 OLTP 数据库中的 transactional replication 设置为用于报告目的的辅助数据库。
【讨论】：
如果您运行的是 2008，您可以使用资源调控器来限制报告用户在生产数据库服务器上的 CPU 和内存使用量。最好的情况是有一个专用的报告服务器和数据库，但这可以工作。
【讨论】：
最简单的方法是设置一个用于报告的服务器并将您的数据库复制到该服务器上。针对报告服务器运行报告。
这对于报告可能不是很有效，如果您的报告工作量很大，可能会出现性能问题。
根据您的报告要求，您可能希望在数据仓库和针对您的操作数据库副本的一组报告之间进行一些操作。更简单的、特定于系统的扁平化报告结构通常可以相当快地实施。构建一个基本的 ETL 流程，通过每晚刷新来填充它，您将获得可以合理有效地报告的内容。
对于更复杂的分析要求，或者如果您想使用多维数据集，您可能不得不硬着头皮建立适当的仓库或数据集市。
在后一种情况下，SQL Server 附带了一个名为 Report Builder 的工具（从 SQL Server 2005 开始），可以将其视为穷人的业务对象。这可用于提供针对报告数据库的临时报告功能。但是，由于您无法控制该工具生成的 SQL，因此如果您尝试将其与操作数据库中的原始数据结构一起使用，它的性能可能会很差。从这类工具中获得好的结果往往需要一个结构化的数据库，以便与工具和 ETL 处理很好地配合使用，从而清理数据，使其表现得相当好。
【讨论】：