There's so many systems out there that are written in T-SQL it's starting to scare me. There are valid arguments for having stored procedures when security is a priority, or for complex queries where performance is a priority, but I find if you give an inch certain programmers take a mile. The inner DBA comes out like a werewolf. And the next thing you know your entire system is written in stored procedures.
It seems that it all starts with a handful of "complex" reports. These reports are "easier to do in SQL". "We don't have a model for this and we need the report now" is the usual excuse for bypassing the domain layer and going straight to the database. Then as the number of reports grow, you slowly realize that your system is morphing from a "good enough to be in a textbook" multi-tier C# architecture into a "quick-fix" one tier SQL dog.
Maybe I've just had bad experiences. The problem companies face is that of auditing SQL, and being alerted when the SQL is doing more than it should be. I've been investigating C# source code metrics, but maybe it's time to start looking at SQL metrics.
T-SQL seems so archaic. I've never seen stored procs properly managed through source control. I haven't heard of a decent solution for versioning stored procedures. I rarely see any re-use in stored procedures. Debugging stored procs feels like you're in an 80s debugger. You can't pass more than flat parameters to stored procs. It's like a technology stuck in time!
Considering we spend the majority of our coding time working with data or databases, wouldn't you think that someone would have DONE something about this? How come other languages have developed so far and have become so elegant, but SQL is about as pretty as COBOL? Why hasn't anyone addressed versioning of SPs?
I think it's time people started thinking about these problems.
I feel better now that's out of my system.