January 4, 2013 at 5:56 pm
kl25 (1/4/2013)
In terms of finding rows for your cleanup, Dwain's approach and mine will give you the same result so it comes down to speed. How many rows are you looking at cleaning up? I didn't do any performance testing so I'm not sure which approach is faster, REPLICATE or PATINDEX. If it's only a few rows, it probably doesn't matter. If you're talking about millions of rows, performance testing might be helpful.I haven't used PATINDEX before--thanks for the new thought Dwain! I suspect that in performance testing that will be the faster approach but testing would show for sure.
If you haven't seen PATINDEX before, you've got to read the 4th article in my signature links. It provides a very powerful tool for putting patterns to work for you.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
Viewing post 16 (of 15 total)
You must be logged in to reply to this topic. Login to reply