1

On hand is a requirement for a report that needs to perform a substring operation and grouping on the chopped strings in a column. For example, consider my over-simplified scenario:

Among others, I have a column called FileName, which may have values like this

  NWSTMT201308201230_STMTA
  NWSTMT201308201230_STMTB
  NWSTMT201308201230_STMTC

etc.

The report I'm working on should do the grouping on the values before the _ sign.

Assuming the volume of data is large, where is the best place to do the substring & grouping - in the Stored procedure or return the raw data and do all the work in SSRS?The expectation is to have good performance and maintainability.

4

1 回答 1

1

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

我对选项的看法：

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

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

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

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

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

于 2013-08-21T14:36:03.210 回答