sql - SSRS：条件数据集定义的模式

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

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

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

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

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

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

我现在倾向于选择3或4，但是渴望听到什么是首选方法（即使这里没有列出）以及为什么？