September 23, 2009 at 9:19 am
I wanted to get some input from some of you guys that may have seen this before. I currently have 50 + ETL packages that loads our data warehouse. Currently we have all the SQL logic within the packages themselves. For instance, large select statements within the OLD Source. Would it make sense to pull all those pieces of logic, the select and such, in stored procedures or views? Also are there any performance issues associated with this approach? Any other caveats associated with this approach that I haven't mentioned?
Thanks!
September 23, 2009 at 3:16 pm
My preference is to push as much logic as possible to stored procedures. In my experience, the actual code or logic tends to be the component of an SSIS package that changes most frequently. By using stored procedures, you are only having to alter a stored procedure for logic changes, rather than redeploying an SSIS package, which, in my experience, is more prone to errors. Thanks.
September 24, 2009 at 8:50 am
As usual it depends. If your business logic requires rbar you should have it in SSIS. If it can be don in a set based fashion use sp's.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply