SSRS行分组 - 前端或后端

Question

现有要求报告需要执行子字符串操作并对列中的切断字符串进行分组。例如，考虑我过度简化的情况：

除此之外，我还有一个名为FileName的列，它可能包含这样的值

  NWSTMT201308201230_STMTA
  NWSTMT201308201230_STMTB
  NWSTMT201308201230_STMTC

等。

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

假设数据量很大，那么最好的位置是子串和？分组 - 在存储过程中还是返回原始数据并在SSRS中完成所有工作？期望具有良好的性能和可维护性。

Answer 1

如你所述，有几种不同的可能性。对此没有正确答案，但当然每种方法都有优点和缺点。

我对选项的看法：

1. 在SQL服务器上：作为视图中的计算列。
   • 专业版：如果查询将被多个报告或其他查询使用，则易于重复使用。
   • Con：字符串操作语言很差。
2. 在SQL Server上：查询中嵌入的查询，计算仍在查询中。与1类似，但现在您失去了重用的优势。
   • Pro：报告非常便携：可以针对生产数据测试更改，而不会干扰当前的生产报告。
   • Con：与1相同，SQL中的字符串操作并不好玩。不那么集中，可能更难维护。
3. 在报告中，在需要的公式中。这种方法有许多缺点，但有一个好处：
   • 专业：写起来很容易。
   • Con：维护非常困难;找到公式的所有出现都可能是一种痛苦。仅限于类似VB脚本的命令。 SSRS中的编辑器创作环境并不好玩，缺乏许多基本的代码编辑功能。
4. 在报告中，在报告的集中代码中。
   • Pro： VB.NET语法，全局变量，易于维护，每个报告都有集中代码。
   • Con： VB.NET语法（我非常喜欢C＃。）编辑器并不比公式窗口好。你可能仍然会在另一个窗口中写这个并切割并粘贴到目的地。
5. 自定义.NET程序集：编译为.dll，并从报告中调用。
   • Pro：使用任何.NET语言，完整的Visual Studio编辑器支持，以及简单的源代码控制和代码集中。
   • Con：设置更加挑剔，报告部署需要将.dll部署到SSRS服务器。

所以我的决策过程就像：

• 这只是一次性的简单公式吗？使用方法3。
• 这是用SQL干净地表达的，只用在一个报告中吗？方法2。
• 在SQL中干净地表达并用于多个报告或查询？方法1。
• 在Visual Basic中比SQL更好地表达？方法4。
• 与多个开发人员进行的重大开发工作？方法5.

我经常会开始关注方法3，然后意识到我已经使用了太多的地方，我应该早点集中。此外，我们的团队非常熟悉SQL，所以推动前两个选项比一些商店更多。

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