问SQL Server不就是用来报告开销的吗？

EN

那得看情况。

一年甚至一个月的详细数据完全有可能在数据库中得到更好的处理，在该数据库中，模式针对报告进行了优化，甚至只是索引模式不同。

这也取决于报告的类型，如果你要比较当前月份的趋势与过去几个月的趋势，将它们放在同一个数据库中要容易得多。如果您有日均移动平均值，那么在单个数据库中执行该操作要比在数据库边界上执行该操作容易得多。

就过度标准化而言--这可能意味着很多事情。

在scale应用程序中，应用程序(OLTP)和报告(DW)负载可以且通常是非常不同的。OLTP事务一次处理少量记录，经常发生，可以是select、insert或update。DW查询倾向于处理更多的记录，发生的频率较低，应该是只读的。

对于较小的应用程序或还没有数据历史记录的年轻应用程序，性能不会成为问题。但是，随着应用程序的发展和普及，将需要一个单独的数据库，并最终需要一个单独的服务器来满足应用程序性能和分析报告的业务需求。

以下是这两种类型的工作负载的概述。

OLTP查询通常是由开发人员编写的，这些开发人员对应用程序性能具有既得利益，并且确切地知道他们试图满足的业务功能类型。同一查询在一天内执行多次，问题会被忽略。以下是工作负载类型的一些示例。

• 记录销售。
• 验证

产品详细信息。

• 更新用户配置文件。

DW查询可以由用于即席报告的查询工具自动生成，也可以由几乎没有技术经验的分析师或业务用户直接编写。有些人可能更喜欢对他们选择的工具进行select *操作，比如SAS或Mathematica。如果不使用脏读操作，这些类型的查询可能会对OLTP应用程序的性能造成严重影响。即使是编写良好的查询来进行趋势分析或将大量客户分组为百分位数，也可能需要全表扫描，因为它需要所有数据。可能需要回答的问题类型。

• 今天、本周、上个月卖出了多少辆自行车。
• 一天中最受欢迎的时间段是什么时候销售利润率高的产品。
• 为我提供了一年中页面浏览量的趋势图。

我认为拥有一个独立于生产/事务服务器的报告服务器通常是一个好主意。我使用完全“非规范化”的数据结构设置了报告服务器，这会使关系纯粹主义者cringe...but它是一个报告服务器，所以这无关紧要。

用户喜欢能够在没有DBA阻挡的情况下访问“他们的”数据(当然，报告数据库是只读的)。

一组例程(或者更好的是无人值守的夜间批处理过程)通常是一个很好的解决方案，它从生产服务器中提取数据，并将每个数据汇总、汇总、交叉分析和清理，唯一的目的就是以尽可能快的方式将有用的信息提供给用户。

在我的情况下，肯定减轻了我的工作量，因为“你能为我创建一份报告，显示……”请求类型。让用户访问数据，并在工具上对他们进行培训，让他们自己去做。