SSIS vs. T-SQL

This is a common question which comes often before any developer to choose between the two as to follow which path to choose as SSIS or T-SQL for developing ETL solutions.

well i also got similar scenario some time back and was in a dilemma to decide this.

on a big picture it's always better to go with conventional way i.e. using T-SQL and not to go with the tool.
But on doing some more reading and research over many blogs and forums and also the development phase of my work over some 2 and a half odd years. I found some good reasons and explanations over this as not to always stick to a particular approach and do proper analysis of the requirements to take a decision.

Below are some of the key points which i was able to collect regarding this.

1. If the data does need to be persisted temporarily it can be to a raw file in SSIS whereas T-SQL requires temporary tables for which there may be a management/security overhead.

2. SSIS have a very good visual representation of the "work".

3. SSIS manages memory very efficiently, which can result in big performance improvements compared to     T-SQL.

4. Bad data can be captured to a different data sink for examination later in SSIS as it have an in-built debugger where we can attach the data in between the transformations without using any temporary object and can copy that data to excel file to analyze.

5.  Exception Handling is better in SSIS as compared to T-SQL.

6. Data-flows are, to some extent, self-documenting so improves code understand-ability as far as documentation is concerned.

7. User-controlled parallel execution of data-flows is possible where it isn't really in the inherent batch operated world of stored procedures.

8. "Heavy-lifting" of data can occur on a different to machine to that storing the data.

Regarding the performance impact on the source server, since the Stored Proc's have to do all the work on the server itself, while the data flow can be pulling data in an asynchronous way and doing the heavy lifting on a different machine.

9. By default, events containing very pertinent information such as "component "<component name>" (5824)" wrote 2398156 rows" are rose which might be very useful for logging and process tracking in case of any failures or logging scenarios.

10. For each Loop Container in Integration Services takes a data type of System.Object (not the physical SQL table), which is an in-memory object that is native to the Integration Services, which is very effective in terms of performance optimization as compared to Temp tables\tables variables\cursors.

Hope you find this post Useful.

Do comment if it you need any further information on this or if you find anything here which doesn't looks convincing.

Happy Learning !!