trubolotta (9/22/2010)
This appears to be one of those articles that creates a problem based on poor design and purports to correct it using some bloated functionality of SQL Server. If the table were properly designed with uniqueness constraints, the problem would not exist. Allowing duplicate data into the table in the first place is the problem, not fixing it after the fact. The more likely scenario and the one I have seen most often comes from importing data from poorly designed databases or poorly trained users.It seems to me we have entered a phase with SQL Server fuctions in search of problems to justify their cost and footprint, no matter how contrived those problems may be.
This is not a solution looking for a problem. Almost every OLTP database I see has: lousy performance, dirty data, duplicate rows, poor indexing, inefficient queries, cursors, WITH NOLOCK hints on everything, thin to no security, no integrity checks, & never tested their ability to restore their system.
Often created by developers who "know a little TSQL" or a DBA constantly apologising that this was his first project when he joined the company & he's learnt a lot since then. OR they were really short of time & he just didn't get around to fixing it.
Also I've never done a datawarehouse or BI project where the cube didn't highlight a drastic need to fix up the data they thought was perfect.
So ... It is possible that the only companies that ask me to help with their database, are those who know they have a problem. And don't have a team of skilled DBA's. So the sample I see is likely to skewed.
Or it is possible that you've only worked on well funded projects that benefit from you high level of DBA skills.
Either way, trust me. There is a huge line of people with no idea how to fix their data that will benefit from this thread.