October 28, 2012 at 12:41 am
Does anyone use the SCD transformation in their production ETLs? In my two previous DW jobs, we never used the SCD transformation as the general consensus was that it "sucked" (yeah, I know -- real technical explanation).
Now at a new job, I've got a consultant saying that they use SCD transformations all the time. The performance does seem to be really poor, even with relatively small dimensions (5000 rows). My gut feeling is that this is just being lazy -- it's being used even on simple Type 1 dimensions.
I'm not going back and redoing ETLs, but I don't want to continue the practice going forward.
I'm just curious what everyone else's experience and thoughts are regarding the SCD transformation.
Thanks,
Rob
October 28, 2012 at 8:38 am
robert.gerald.taylor (10/28/2012)
Now at a new job, I've got a consultant saying that they use SCD transformations all the time. The performance does seem to be really poor, even with relatively small dimensions (5000 rows). My gut feeling is that this is just being lazy -- it's being used even on simple Type 1 dimensions.
I agree with you but you're fighting prior status quo (which is lazy in and of itself). If you want to not use SCD transformations going forward, then you're very likely going to have to take the following steps...
1. Design an alternate method and write the code or method (or whatever) for it.
2. Prove that the alternate method is substantially faster across a large data set and why being faster is a good thing. You'll get questions like "If the run finishes overnight, who cares if it takes 4 hours or 4 minutes?". Yeah... I know. Questions like that don't show forward thinking insofar as scalability but that's the reality of problems like this.
3. Prove that the alternate method is either easier or not too much more difficult than the current method.
4. Then you'll have to prove that the new method is either cheaper or at least not much more expensive to implement than the old way because, just like when someone runs for election, every little detail is going to be raked up. They'll actually spend more money justifying why not to change than you'll spend justifying the change. The costs should include the "training" people will need to get used to the new method.
Think "ROI" here. You're trying to bring about change contrary to the words of an, apparently, trusted resource. Even if it's for the better, it's still a change and people resist change especially for something that's already working even if it works poorly. You're going to have to not only prove there's a better way, but why it's a better way, that it's "better enough" to justify a change, and what both the short and long term advantages actually are. Otherwise, people will continue to use the excuses of "We've always done it this way" and "We've never done it that (meaning "your") way before".
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2012 at 9:13 pm
Jeff,
Thank you for that thoughtful reply; you make a good point about having to sell/justify the change with ROI. I can create a template package that will/should be easy enough to make the change palatable.
Thanks,
Rob
November 1, 2012 at 12:47 am
Thanks for the feedback, Rob. We're all busy but problems like the one you're having are a keen interest of mine. If you have the time, I'd sure like to hear how this one all turned out when all is said and done.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply