参数化OLEDB源查询

Question

我在SSIS中创建一个ETL,我希望我的数据源是限制查询,比如select * from table_name where id='Variable'.这个变量是我定义为User created变量的.

我不明白我的源查询如何与SSIS范围变量进行交互.

目前唯一的选择是

• 表
• 变量表
• SQL命令
• 来自变量的SQL命令

我想要的是拥有一个带有变量作为参数的SQL语句

Answer 1

简单.选择SQL command数据访问模式.输入带有问号作为参数占位符的查询.然后点击Parameters按钮,您的变量映射到Parameter0了在Set Query Parameters对话框:

有关更多信息,请访问MSDN.

Answer 2

@ Edmund方法的另一种替代方法是在另一个变量上使用Expression来构建字符串.假设您已经定义了@ [User :: FirstName],那么您将创建另一个变量@ [User :: SourceQuery].

在此变量的属性中,将EvaluateAsExpression设置为True,然后设置类似于"SELECT FirstName, LastName, FROM Person.Person WHERE FirstName = '" + @[User::FirstName] +"'"双引号,因为我们正在构建一个SSIS字符串.

不应该谴责这种方法有两个重要原因.

高速缓存

这种方法将在SQL Server中使用基本相同查询的N个副本来扩展您的计划缓存.它第一次运行并且值为"Edmund"SQL Server将创建一个执行计划并保存它(因为构建它们可能很昂贵).然后运行包,值为"Bill".SQL Server检查它是否有此计划.它没有,它只有一个给Edmund,所以它创建了另一个计划副本,这次硬编码给Bill.泡沫冲洗重复,并观察你的可用内存减少,直到它卸载一些计划.

通过使用参数方法,当计划提交到SQL Server时,它应该在内部创建计划的参数化版本,并假定所提供的所有参数将导致相同的成本计算执行.一般来说,这是理想的行为.

如果您的数据库针对临时工作负载进行了优化(默认设置为关闭),那么应该减少这一点,因为每个计划都将进行参数化.

SQL注入

构建自己的字符串会遇到另一个令人讨厌的问题,那就是你打开SQL注入攻击,或者至少可以获得运行时错误.它就像拥有"d'Artagnan"的价值一样简单.该单引号将导致您的查询失败,从而导致程序包失败.将值更改为"'; DROP TABLE Person.Person; - "将导致极大的痛苦.

您可能认为安全引用一切都是微不足道的,但是在您查询的任何地方始终如一地实施它的努力超出了您的雇主所支付的费用.更是如此,因为提供了本机功能来做同样的事情.