用SQL Server寫指令碼和程式設計實現SSIS包的擴充套件

　SQL Server 2005中用來替代資料傳輸服務(DTS)的SQL Server綜合服務(SSIS)，包含了很多工具用於匯入資料並將其轉換為有意義的資訊，而不僅僅是被動的匯入。但是要注意的是，這個新的SSIS工具有時候並不能完全覆蓋你要做的所有事情。因此，微軟提供了兩種基本方法來擴充套件SSIS的功能。一種方法對那些沒有很多程式設計經驗，或者是不需要編寫複雜程式的人們來說相對簡單；另一種方法就是複雜的，它可以讓喜歡挑戰的程式設計師深入SSIS，對其進行很大程度上的擴充套件。

　　簡單方式：指令碼

　　我們中的大多數人都在某種程度上至少接觸過指令碼，SSIS通過在SSIS包中使用VB .NET來為程式設計師提供編寫指令碼動作的功能。指令碼的範圍，與客戶專案相比，是十分小並且集中的；那是在你需要在現有的包允許或者已經完成的範圍內多少做些修改的時候使用的。

　　在SSIS包裡面，有兩個元素是你可以用來新增指令碼的：Script. Task(在綜合服務設計應用程式的控制流視窗中)和Script. Component(在資料流視窗中)。它們倆的應用環境稍微有些不同。

　　指令碼任務(Script. Task)是你用來在包裡面實現一般目的的流控制的——它比指令碼元件(Script. Component)更加全域性化，功能更強大，但是也複雜得多。它在包的資料流之外執行，不能被資料流的工作方式約束，雖然指令碼任務通常都是隻有包被觸發的情況下才執行(雖然你可以構建在異常裡面)。任務也支援斷點和除錯，這在你編寫了比較精細的具有控制邏輯或者完成某類決策制訂的指令碼的時候比較有用。關於指令碼任務的一個例子就是查詢活動目錄，尋找一些關於資料的資訊，或者是與另外一個資料倉儲對話——都是在執行包之前。

　　指令碼元件更加貼近資料流工作的方式。指令碼元件不是在整個包中之執行一次，而是它的主要處理為每個需要處理的資料行執行一次。指令碼元件有三個比較基本的執行環境:資料來源、資料轉換，或者資料目標。元件的互動性也比較小——它並不支援指令碼任務支援的那種型別的除錯，這是其一。使用指令碼元件的大多數情況是類似一行接一行的轉換，構建客戶ODBC目標，或者是不能通過SSIS本地函式處理的不重要的錯誤處理或者轉換動作。

　　高階方式：對客戶物件程式設計

　　雖然SSIS包裡面的指令碼很強大，有時候它仍然無法完成某些任務。在一些情況下，你可能需要從頭編寫(或者其他人編寫)一個客戶SSIS 擴充套件。這不是輕鬆完成的事情；它需要你從根本上完全理解程式設計。但是對於客戶物件，它可能會以某種方式是使用SSIS，但是這方式絕對不是簡單的自動化任務。

　　例如，如果你的資料來源不支援任何現有的SSIS轉換(例如，一些古怪的不再被製造廠商支援的私有資料來源)，你可以編寫客戶連線管理物件來允許像在本地那樣使用這個資料。同樣，你可以建立客戶任務，日誌提供商，或者是通過SSIS實現的帶有同樣的程式設計庫的資料流元件。

　　以上談到的每一種型別都可以作為SSIS支援的語言中的基本類、屬性和方法集使用：Visual Basic, C#, C++, J# 和Jscript。C++, C# 和VB更容易產生最好的結果，因為在這些情況下它們在更大程度上被開發人員和供應商支援。想法就是你所使用的語言不應該成為你的障礙；它們都可以插入到同一個外部程式設計介面。你還可以為客戶物件建立使用者介面，通過標準的Windows窗體，無論是否需要它們。

　　一個極端強大的此類例子就是，你可以通過SSIS客戶物件建立可定製的前端調查裝置。我們說，如果你想要建立一組程式類來為集合中的每個物件集執行任務，例如，資料庫中的一組表。如果你想要在很廣泛的範圍內實現這樣的一個動作，並且不需要每次都重新發明一次輪子，這就是一中最好的實現方式。當你對一些新型別的資料(例如上面例子中提到的)建立客戶連線管理器，並且想要在上面建立客戶前端動作的時候，它就特別有用處了。

　　結論

　　你擴充套件SSIS的方式，無論是指令碼還是程式設計，都是根據你的需求和你的能力來決定的。因為你可以使用兩種方式——即使在同一時間!——你都可以不用費很多力氣。你還可以根據需要進行修正和匹配。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-544963/，如需轉載，請註明出處，否則將追究法律責任。