通過 SSIS 進行的所有數據轉換

我目前工作的一些人已經決定，進入我們數據庫的所有數據轉換都必須通過 SSIS 完成。這意味著將不再使用任何用於轉換數據的舊程式碼，例如視圖、儲存過程、函式等。他們目前執行的轉換將僅通過 SSIS 完成。我正在嘗試列出我們可能面臨的潛在問題，但我對 SSIS 的了解不如我對 SQL Server 的了解那麼多，因為我是這裡的 DBA。我看到的問題之一是試圖查看 SSIS 與 sql 對像中的性能問題。我還缺少什麼？我們正在使用 Microsoft SQL Server 2016 SP2 和 SSIS 2016。

我已經看到這樣做了。雖然我不會推薦它，但從流程和技能組合的角度來看，它確實具有一些優勢。您嘗試這樣做的主要原因是有一個一致的拖放過程來建構，重要的是，更改 ETL 過程。

問題：

1. 性能。在 SSIS 數據流中執行轉換只是比使用 TSQL 慢。

2. 生產力。使用 TSQL 可能是一項更難的技能，但對於可以兩者兼得的人來說，使用 TSQL 建構和測試比使用 SSIS 數據流更有效率。

我喜歡大衛的回答，我會用它來提出“反對”SSIS 的論點。

但是，如果您想要一個快樂的媒介，您也可以讓 SSIS 使用過程/視圖作為腳本任務來進行組織和視覺化/流目的。

例如：我使用混合形式來：

1. 從另一個數據庫/表/平面文件中獲取數據（通過源）
2. 如果使用了平面文件，請將其從導入目錄移動到“工作目錄”
3. 通過腳本任務 (C#) 轉換/驗證數據
4. 將數據推送到臨時表（通過使用底層 T-sql 過程執行 SQL 任務）
5. 將其合併/更新到最終目標表中（通過使用底層過程執行 SQL 任務）
6. 將導入/更新的行記錄到表中（通過使用底層過程執行 SQL 任務）
7. 重命名/移動文件（如果使用了文件）到存檔目錄（通過複製/移動文件任務）
8. 發送包裹已完成的電子郵件（以及每個文件的統計資訊）（通過發送電子郵件任務）

這樣，當有人查看我的 ETL 流程時，他們可以輕鬆判斷流程並找到有問題的對象，但我仍然可以擁有帶有 T-SQL 組件的包的“模組化”。

這也使複製我的過程變得更加容易。如果有新表，我只需複制/粘貼（在一定程度上）並將流程調整到新組件。我的模板包已經有我的 dev/prod/qa 連接/目錄，這使得事情更易於管理。

引用自：https://dba.stackexchange.com/questions/228377