我有一份 SSRS 报告，其中有 3 个数据集来自一个数据源。主数据集是一个存储过程，它根据由其他两个数据集提供支持的一组参数聚合一些数据。
支持此报告的主要存储过程有 4 个参数。一个是数据类型的 ID，两个是开始和结束日期，第三个只是一个标志参数。flag 参数是多值参数，我想在其中传递多个也是 VARCHAR 值的标志值。
在我的 @Flag 参数的存储过程中，我有共同点：
WHERE [Flag] IN (@Flag)
然后当然 SSRS 报告上的 @Flag 参数设置为允许“多个值”，这些值也是从从维度表中提取这些 @Flag 值的查询填充的。
我的问题
在大多数情况下，在处理 INT 值时，使用相同的技术是有效的。但是，当我处理字符值时，它失败了。如果我选择一个标志，报告会神奇地工作。如果我选择了多个标志，它似乎不会将这些标志正确地传递给存储过程，并且不会返回任何结果。
直接在存储过程中测试多值标志时：
WHERE [Flag] IN ('A', 'B', 'C')
存储过程正常工作。所以问题不在于存储过程，而在于 SSRS 如何将多值值传递给 @Flag 参数。
尝试的解决方案
我尝试对这个@Flag 参数的 SSRS 数据集进行以下调整：
=join(Parameters!<your param name>.Value,",")
还有这个：
=SPLIT(JOIN(Parameters!<your param name>.Value,","),",")
这些都适用于单个值，但从不适用于多值。
我在这里缺少什么？
我有一个字段，它是一个字母数字字段，理想情况下是非唯一标识符的加密字段。它用于以多对多关系关联其他相当大的事实表。我没有此字段的相关维度，因为此 FK 没有其他属性。
示例：Abcdefgh12345
该字段位于一个相当大且不断增长的数据仓库中，其中 Fact 表按时间集群，而不是像这样的键集群。
该列是VARCHAR(50)并且仅在 45 和 50 之间变化。必须检查，但我认为排序规则是SQL_Latin1_General_CP1_CI_AS. 出于优化原因，我不使用 FK。全部由 ETL 控制。
碎片化
由于键的类型，很难索引。它的碎片是由我最近进行的一系列测试管理的，这些测试表明 75% 的填充因子至少是可以管理的，减少每日增量负载的碎片至少一周，直到可能需要完全重建，每周一次就可以了。
表现
随着填充因子从 100% 降低到 75%，插入和读取变得更慢。正如预期的那样，这些记录也越来越大。任何包含包含的索引都在很大程度上推动了插入的性能，但当然可以帮助需要它们的查询提高 10 倍。
题
有没有人有在数据仓库环境中使用字母数字的良好经验？它的处理方式和索引现在很好，但我认为它可能会更好。我正在尝试在 ETL 过程中删除密钥、形成新维度并添加更易于管理的密钥的想法。
我有一个从未知来源系统以 gunzip 压缩的文档。它是使用 7zip 控制台应用程序下载和解压缩的。该文档是一个 CSV 文件，似乎以 UTF-8 编码。
然后在压缩后立即上传到 Azure Data Lake Store。然后有一个 U-SQL 作业设置，只需将它从一个文件夹复制到另一个文件夹。此过程失败并引发值的 UTF-8 编码错误：ée
测试
我从商店下载了该文档并删除了所有记录，但带有 Azure 标记值的记录除外。在 Notepad++ 中，它将文档显示为 UTF-8。我再次将文档保存为 UTF-8 并将其上传回商店。我再次运行该过程，该过程成功，该值为 UTF-8
我在这里缺少什么？原始文档是否可能不是真正的 UTF-8？是否还有其他原因导致误报？我有点困惑。
可能性
环境/工具
USQL
只是定义架构的基本 USQL 作业然后将所有字段选择到一个新目录。除了省略标题之外，不会发生任何转换。该文件是 CSV，用逗号分隔的字符串中的双引号。无论数据类型如何，架构都是字符串。尝试的提取器是 TEXT 和 CSV，两者都设置为编码：UTF8，即使根据系统上的 Azure 文档，两者都默认为 UTF8。
其他注意事项