Jeff Moden (1/10/2012)
Of course, you could also pre-process tables before they come anywhere near SQL Server but I've found that writing such code is a bit of a fright because you might not have set based, declarative tools such as are available in SQL Server to keep from having to write read/write routines with lots of loops and decisions on your own.
Actually, performing loops and tests in other languages is much easier. T-SQL is not that great a language in regards to either performance or feature sets. T-SQL's main advantage is that it has a database system hooked up to it.
I don't think you should give up on loops and tests just because T-SQL is not that great a programming environment, unless you're really just not that interested in programming in general.
I'll have to resort to the "It Depends" aspect. If you want to check all data in a "field", it's a whole lot easier to do a test for it in a column in T-SQL than it is to write code to cycle through every row of that "field". Because T-SQL will use the very low-level "Pseudo Cursors" behind the scenes, it'll do it all at the same or almost the same speeds as writing an external validation script.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs