我有一些SQL，它对GL账号和成本中心的组合执行复杂的逻辑，如下所示：
WHEN (@IntGLAcct In (
882001, 882025, 83000154, 83000155, 83000120, 83000130,
83000140, 83000157, 83000010, 83000159, 83000160, 83000161,
83000162, 83000011, 83000166, 83000168, 83000169, 82504000,
82504003, 82504005, 82504008, 82504029, 82530003, 82530004,
83000000, 83000100, 83000101, 83000102, 83000103, 83000104,
83000105, 83000106, 83000107, 83000108, 83000109, 83000110,
83000111, 83000112, 83000113, 83100005, 83100010, 83100015,
82518001, 82552004, 884424, 82550072, 82552000, 82552001,
82552002, 82552003, 82552005, 82552012, 82552015, 884433,
884450, 884501, 82504025, 82508010, 82508011, 82508012,
83016003, 82552014, 81000021, 80002222, 82506001, 82506005,
82532001, 82550000, 82500009, 82532000))
总的来说，整个事情在UDF中表现不佳，特别是当它全部嵌套并且步骤的顺序很重要时等等。我还不能让它成为表驱动的，因为业务逻辑非常错综复杂
所以我正在进行一些探索性的工作，将它转移到SSIS中，以便以一种不同的方式看待它。然而，在我的脚本任务中，我必须使用VB.NET，所以我正在寻找替代方案：
Select Case IntGLAcct = 882001 OR IntGLAcct = 882025 OR ...
这显然更加冗长，并且会使整个过程非常困难。
即使像({90605, 90607, 90610} AS List(Of Integer)).Contains(IntGLAcct)这样的东西也会更容易移植，但我无法让初始化程序给我一个像这样的匿名数组。这些小集合中有这么多，我不确定我是否可以提前创建它们。
真的需要在一个地方。业务定期改变这种逻辑。我的策略是使用udf镜像他们的旧“包含”文件，但性能一直很差。现在每个函数只需要2或3个参数。事实证明，在现有系统的一个黑暗角落里，他们实际上构建了一个包含所有这些结果的数百万行表 - 即使预先调用的表没有使用太多。
所以我的新实验是（因为我仍在构建大规模的交叉连接表以协调该过程的这一部分）继续使用表而不是代码，但继续在SSIS期间填充此表阶段而不是调用udf 1200万次 - 因为我的udf版本基本上停止了在合理的时间范围内工作，而且DBA现在没有多大帮助。然而，我知道SSIS可以非常有效地处理这些行 - 因为每个月我都会在几分钟内从遗留系统中带来已知的好结果数十亿个行表并运行查询以协调与新版本没有差异
理论上，SSIS代码将成为业务逻辑的守护者，并且可以从中构建高效表（基于所有已知的参数组合）。当然，如果我可以将逻辑简化为真正的逻辑表，那将是最终的设计 - 但目前还不能预见到。答案 0 :(得分：1)
试试这个：
Array.IndexOf(New Integer() {90605, 90607, 90610}, IntGLAcct) >-1
答案 1 :(得分：0)
如果您对传入的数据集使用了条件拆分转换，然后使用了类似的表达式（我不确定您的GL帐户是否已修复或者您是否要动态传递它们），那么该怎么办？结果？然后，您可以根据需要从中获取结果数据。