May 12, 2010 at 12:11 am
Hi Guys,
A recent suggestion at my company is to ban SSIS, that it not be used under any circumstances. The proposal is to replace any use of SSIS with a .Net program. My initial reaction was...not positive. But I am willing to at least consider the idea and weigh it on it's merits.
What I am interested in knowing is whether anyone else out there has taken this path, or has any input as to the wisdom of this approach?
Thanks,
Steve.
May 12, 2010 at 3:04 am
Whoever has suggested this must have their reasons, it would be interesting to find out what they are. It doesn't really make sense to replace a tool that is free (if you already have SQL Server licence) with tools/methods that you write yourselves. Why reinvent the wheel.
May 12, 2010 at 3:07 am
All depends on the quality of your .net developers.
SSIS removes all the framework from an ETL Process, (ie you dont have to worry about the nitty gritty of reading and writing the data) .
Additionally , tasks can work in parallel , multi threaded operations can be problematic to develop and implement.
May 12, 2010 at 3:09 am
Did the people who made this suggestion give a reason?
I suppose you could reimplement SSIS yourself in .net, but it would be a massive waste of time and resources.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 12, 2010 at 8:46 am
I am with the other posters, the person who suggested this must have their reasons. Perhaps they should list them out and generate a pros/cons list. And then open that list up to others to add to.
My first thought though was that you probably have a lot of .NET developers who don't know anything about SSIS and don't want to learn it.
I can say this with little reservation, you will not be able to write a .Net program in 99% of the cases that will out-perform data movement in SSIS. In addition to that I (an others familiar with SSIS) could generate a package to do a simple copy in about 60 seconds.
We have had this discussion before here on SSC, the consensus is that SSIS should be used over .NET for data movement. The exceptions to that are few and far between.
CEWII
May 12, 2010 at 5:39 pm
Thanks for your replies everyone.
The reasons are such: the company has, over time, accumulated a large set of poorly written DTSX packages that are causing no end of grief (ironically written by a .Net developer with subsequent cut-n-pasting jobs by end users compounding the problems.) After a reshuffle the realization dawned that these needed fixing. Hence the opinion that since the existing SSIS implementation is crap, SSIS is crap, and so should be banned.
If there are other reasons I'm not yet aware of them but as this is going to be a hot topic of discussion for the next couple of days. I've no objection to .Net being used in conjunction with SSIS, but banning SSIS outright seems like a knee-jerk reaction.
Steve.
May 12, 2010 at 6:25 pm
It is a knee jerk reaction and should be combatted with some examples of how SSIS is not crap.
Take some of the crap packages and rewrite them so they functional better and show them the difference. End users should not be copying the dtsx packages, that would be a flaw in process and lead to a lack of control on the data and environment. That should also be brought up in conjunction with a solution that is viable.
.Net has its qualities and SSIS has its qualities. They could be used in conjunction and make many things considerably better.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 12, 2010 at 9:08 pm
So their reasoning is that internally they did a poor job implementing it and a poor job of source control. So we are blaming the technology.
An analogy would be a SQL developer writing poor .NET code and then the company saying we should ban .NET because we have had a bad experience.. Its ludacris.
I like the idea of re-writing a package to show a good implementation.
SSIS is GREAT for moving data, even a marginal implementation will move data pretty well, a really optimized implementation will BLOW THE DOORS OFF just about anything you can do in .NET natively AND you can develop it a lot faster.
I've written an obscene amount of SQL code and a huge amount of .NET code, and the statement "the right tool for the right job" is right on. Each tool has its place.
Also, can I ask why users are editing the packages? What about source control? What about code quality reviews?
CEWII
May 13, 2010 at 1:22 am
CirquedeSQLeil (5/12/2010)
It is a knee jerk reaction and should be combatted with some examples of how SSIS is not crap.Take some of the crap packages and rewrite them so they functional better and show them the difference. End users should not be copying the dtsx packages, that would be a flaw in process and lead to a lack of control on the data and environment. That should also be brought up in conjunction with a solution that is viable.
.Net has its qualities and SSIS has its qualities. They could be used in conjunction and make many things considerably better.
Jason, you pretty much have it spot on. I would mention that the end-users inherited the packages when the developer left, and I think they're glad to be rid of them now (due to the reshuffle.) We do have some fine DTSX packages here, but it's the dodgy ones getting all the airtime at the moment.
Steve.
May 13, 2010 at 1:43 am
Elliott W (5/12/2010)
So their reasoning is that internally they did a poor job implementing it and a poor job of source control. So we are blaming the technology.An analogy would be a SQL developer writing poor .NET code and then the company saying we should ban .NET because we have had a bad experience.. Its ludacris.
I like the idea of re-writing a package to show a good implementation.
SSIS is GREAT for moving data, even a marginal implementation will move data pretty well, a really optimized implementation will BLOW THE DOORS OFF just about anything you can do in .NET natively AND you can develop it a lot faster.
I've written an obscene amount of SQL code and a huge amount of .NET code, and the statement "the right tool for the right job" is right on. Each tool has its place.
Also, can I ask why users are editing the packages? What about source control? What about code quality reviews?
CEWII
Ah Elliot, great minds think alike. I considered trundling out the .Net comparison earlier today but I knew I'll get howls of protest and denials.
End users, being internal departmental users not customers, got lumbered with the packages when the developer left. As to source control, very little db-related was in source control when I started although every tiny scrap of .Net code certainly was. 'This is changing but the first time I suggested it there was a great deal of mirth. "Put database code in source control? What's this DBA been smokin'?"
I digress. Been a long day and watching WWF has given me a good idea what to do with my office chair.
Steve.
May 13, 2010 at 2:49 am
Whatever the whys and wherefores , the tool is being blamed for a bad job by a bad workman.
Any developer can screw up any development.
May 13, 2010 at 8:21 am
Fal (5/13/2010)
Ah Elliot, great minds think alike. I considered trundling out the .Net comparison earlier today but I knew I'll get howls of protest and denials.End users, being internal departmental users not customers, got lumbered with the packages when the developer left. As to source control, very little db-related was in source control when I started although every tiny scrap of .Net code certainly was. 'This is changing but the first time I suggested it there was a great deal of mirth. "Put database code in source control? What's this DBA been smokin'?"
Howls of protest or not I usually like to do that and then explicitly ask how HOW it is any different, put them on the spot to justify THEIR position, they can howl all they want but the analogy is sound. I'll take heat when it is valid, but never when it isn't.
I have long been astounded by the difference in views on source control for database objects.. How is that any different that .NET code? How is it any less valuable? In most cases if you lose that code you are more screwed than if you lost the app code. Amazing..
CEWII
May 13, 2010 at 8:50 am
Also SSIS holds the ETL world record of loading 1TB of data in under 30 minutes, would like to see your developers try to match this performance in .NET.
http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx"> http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx
May 13, 2010 at 11:33 am
Dave Ballantyne (5/13/2010)
Any developer can screw up any development.
Agreed. Any employee can make a good thing suck like a vacuum if not properly done.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 13, 2010 at 11:34 am
steveb. (5/13/2010)
Also SSIS holds the ETL world record of loading 1TB of data in under 30 minutes, would like to see your developers try to match this performance in .NET.http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx"> http://blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx
That is an excellent resource.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply