SSRS 行分组 - 前端或后端答案

【问题标题】：SSRS rows grouping - front end or back endSSRS 行分组 - 前端或后端
【发布时间】：2013-08-23 21:23:33
【问题描述】：

对于需要执行子字符串操作并对列中已截断的字符串进行分组的报表来说，现有的要求是。例如，考虑一下我过于简化的场景：

除其他外，我有一个名为 FileName 的列，它可能具有这样的值

  NWSTMT201308201230_STMTA
  NWSTMT201308201230_STMTB
  NWSTMT201308201230_STMTC

等等。

我正在处理的报告应该对_ 符号之前的值进行分组。

假设数据量很大，在存储过程中进行子字符串和分组的最佳位置在哪里，或者返回原始数据并在 SSRS 中完成所有工作？期望具有良好的性能和可维护性。

【问题讨论】：

可能在数据库中使用索引视图或向表中添加计算列，但可以作为查询的一部分进行计算。
如果它是一个大容量并且您只对聚合结果感兴趣，那么尽可能在数据库中进行...行。

标签： tsql sql-server-2005 reporting-services ssrs-grouping

【解决方案1】：

正如您所提到的，有几种不同的可能性。这没有正确的答案，但肯定每种方法都有优点和缺点。

我对选项的看法：

在 SQL 服务器上：作为视图中的计算列。
- 专业人士：如果查询将被多个报告或其他查询使用，则易于重复使用。
- 缺点： 用于字符串操作的语言非常糟糕。
在 SQL Server 上：报表中嵌入查询，计算仍在查询中。类似于 1，但现在你失去了重用的优势。
- 专业人士：报告非常便携：可以根据生产数据测试更改，而不会影响当前的生产报告。
- 缺点： 同 1，SQL 中的字符串操作不好玩。中心化程度较低，因此可能更难维护。
在报告中，在需要的公式中。这种方法有很多缺点，但有一个优点：
- 专业人士：很容易编写。
- 缺点：维护非常困难；找到所有出现的公式可能会很痛苦。仅限于类似 VB 脚本的命令。 SSRS Authoring 环境中的编辑器并不好玩，并且缺少许多基本的代码编辑功能。
在报告中，在报告的集中代码中。
- 专业版： VB.NET 语法，全局变量，易于维护，每个报告都有集中的代码。
- 缺点： VB.NET 语法（我更喜欢 C#。）编辑器并不比公式窗口好。您最终可能仍会在另一个窗口中编写此内容，然后剪切并粘贴到目标位置。
自定义 .NET 程序集：编译为 .dll，并从报告中调用。
- 专业人士：使用任何 .NET 语言、完整的 Visual Studio 编辑器支持，以及轻松的源代码控制和代码集中化。
- 缺点：设置起来比较挑剔，报告部署需要将 .dll 部署到 SSRS 服务器。

所以我的决策过程是这样的：

这只是一次简单的公式吗？使用方法3。
这是否在 SQL 中清晰地表达并且仅在一份报告中使用？方法二。
用 SQL 清晰地表达并用于多个报告或查询？方法一。
用 Visual Basic 表示比用 SQL 更好？方法 4。
与多个开发人员一起投入大量开发工作？方法 5。

我经常会开始遵循方法 3，然后意识到我在太多地方使用了这个公式，我应该早点集中。此外，我们的团队对 SQL 非常熟悉，因此比某些商店更倾向于前两个选项。

除非您知道自己有问题，否则我会将性能问题放在第二位。将这段代码放在 SQL 中有时会得到回报，但如果您不小心，最终可能会过度调用最终被过滤掉的结果。

【讨论】：