SSRS：条件数据集定义的模式-Java 学习之路

我正在开发SSRS报告，需要用户选择（通过参数）来检索实时数据或历史数据 .

实时和历史数据的来源是SQL Server数据库中的单独对象（实时数据的视图;接受历史数据的日期参数的表值函数），但它们的模式 - 它们返回的列 - 是相同的，所以除了在数据集定义中，报告的其余部分不需要知道它的来源 .

数据集查询从多个数据库对象中提取，并在select中包含连接和case语句 .

我可以采用几种方法根据我所描述的参数选择（其中一些我已经测试过）来显示来自不同来源的数据，如下所示 .

主要目标是确保检索实时数据（主要用例）的性能不会受到逻辑的存在和利用以支持历史用例的不当影响 . 此外，解决方案（包括数据库对象和rdl）的易维护性是次要但重要的因素 .

在数据集查询文本中使用表达式，使用字符串连接有条件地返回包含正确源的完整SQL查询文本 . Pros ：可以解析为任何给定执行的其他'用例'的直接查询 . 报告的所有逻辑都包含在报告中 . Cons ：使用起来很糟糕，并且对冗长的SQL有限制 .
使用报告代码模块中的函数执行与1. Pros 相同的操作：按照1.，但设计时间稍微好一些 . Cons ：按照1.，但也增加了另一层抽象，减少了维护的难易程度 .
在数据库上实现多步TVF，处理参数并使用T-SQL中的逻辑检索正确的数据 . Pros ：t-SQL功能的灵活性，不涉及字符串构建/替换 . 可以从结果中选择*并在报告的数据集查询中应用其他报告参数 . Cons ：与在线查询相比，性能大打折扣 . 在rdl之外移动一些逻辑 .
实现存储过程以执行与3. Pros 相同的操作：按照3，但不容易选择* . Cons ：按照3 .
实现将实时和历史数据结合在一起的内联TVF，但使用虚拟输入参数，在不相关的源的where子句中添加解析为1 = 0的内容 . Pros ：依赖于内联查询方法，其他专业人员按照3. Cons ：感觉就像一个黑客，只为已知返回0行的查询组件添加性能命中 . 增加查询的复杂性 .

此时我倾向于选项3或4，但是渴望听到 what would be a preferred approach （即使这里没有列出），为什么？

1 回答