SSIS中T-SQL强弱分析

　　SQL Server集成服务，又称SSIS，提供了很多不同的机制从数据源产生和抽取数据。其中的一种方式是ExecuteSQL任务，让你能够就像从前端的应用程序传递一些T-SQL语句到后端的SQL Server一样的方式来使用T-SQL语句。这里的T-SQL可以是一个完整的语句，也可以是对现有存储过程的引用。

　　尽管如此，T-SQL并非在SSIS中唯一的获取数据的方式。还有另外的一种方式叫做数据流(Data Flow)任务。这不尽让人们疑惑：为什么要在SSIS中使用T-SQL?为什么不只用数据流?即使要使用它，相对T-SQL，又有什么好处?我视图去寻找对这些问题的答案，并且在Conchango的Jamie Thomson的博客上找到了一些非常详细的回答。在这里我会对这些回答进行一些整理，同时加入从我个人经验中得到的一些见解。

　　使用已有的T-SQL或者存储过程，而不是使用数据流来重新解决问题，将节约大量的时间。如果你拥有一些花费许多汗水和精力而完成的存储过程，没有理由放弃它而去重新编写一个新的;你只需要大胆的使用它。T-SQL仅仅在调用存储过程的语法上稍有不同(主要是参数传递的方式上)，但是这些区别还是会阻止现有的存储过程在ExecuteSQL中被重用。我将在后面深入讨论一些可能引起问题的细节。

　　你的SQL Server程序员无需学习很多新的技术就可以让他们的代码在SSIS中执行。他们可以编写T-SQL代码，就可以简单的拖入SSIS的工作流当中，几乎无需修改，就可以执行。如果你接手别人的工作，并且将其移植到SSIS中，你更倾向于重用已有的工作，而非从新开始。

　　无论你的数据库在哪里，就算不是SSIS运行的设备上，大部分工作都可以完成(可能工作的数据库和SSIS不在同一台机器上)。这也许不是一种优势，但是这种模式也知道注意。这对你有利而非有害。

　　T-SQL使用数据库本身的交易而不是跨MSDTC(如同SSIS一样)。

　　现在，下面是不在SSIS数据流中使用T-SQL的一些理由：

　　某些存储过程无法在预览中显示数据。这个理由具体来讲，不总是可能估计出某个给定的存储过程执行中所产生了哪些列。这就表示，当你需要为某个数据流预先设定输出格式(output contract)时，一些存储过程并不能替代数据流。尽管如此，你可以是使用视图对数据流预览。这个视图必须紧紧的和数据库模式绑定在一起，而且不能改变，除非你对其进行明显的重新编写(比如，你对它进行了编辑)。因此如果你已有一个想在SSIS中作为数据源的视图，那么你可以预览它。

　　SSIS数据流更适合复杂的、需要多个步骤的处理。这些处理包括一些要求如下操作的工作：

• 　　繁多的编程
• 　　从不同个数、不同类型的数据源进行汇总
• 　　结构化的异常处理
• 　　额外的转换
• 　　无法通过SQL进行访问

　　通常，这些任务都无法简单、有效的在T-SQL中进行处理。

　　SSIS数据流是自我注释的。和T-SQL相比，这是SSIS数据流另外一项可能的优势。但是这仅仅是某种程度上是正确的。假如你对访问的数据库模式毫无了解，那么你可能处于黑暗之中。从另外一方面说，存储过程和T-SQL大体上完全不自我注释的——除非那些编写它们的程序员花时间诸条进行注释(这种情况发生的概率有多大?)。

　　综上所述，关于使用T-SQL还是数据流，可以得出两条简单的意见：

　　T-SQL更适合于处理你只需从已有的数据集合中采集数据的操作，而这些采集的操作不会很快发生变化同时不需要大量附加的数据转换。

　　数据流更适合你需要重新设计一整套新的数据转换的情况——在这种情况下，已有的T-SQL无法胜任。这个标准无法准确的衡量除非你对T-SQL非常精通，了解它的限制。因此，为了利用T-SQL和SSIS，你至少需要对T-SQL的了解和SSIS一样深入。

  以上内容转自http://searchdatabase.techtarget.com.cn/analysis/248/3106748.shtml