Often I have seen stored procs used for writing business logic in an application. Sometimes these procs will contain 1000+ lines of code. If I write a method/function in application code that contained 1000 lines it would be rightly criticised. Should long stored procs be broken down into separate procs, like methods in a class would be? What isn’t this done more as it would certainly make code more usable.
Often I have seen stored procs used for writing business logic in an application.
Share
First, I agree with Nat’s answer: the tools (such as debuggers) for T-SQL debugging provide nowhere near the functionality that one finds for other languages.
Second, there are a number of potential challenges when passing values between stored procedures. Passing simple data types is straight-forward. Passing involved data types becomes more complex. Using temporary tables, XML, delimited strings, record sets, etc. require additional coding, create additional overhead, and have performance implications.
My “rule” is that if the input and output parameters can be handled with the standard methods (i.e. standard data types), then breaking up the stored procedure is warranted. If passing the input and output requires a lot of coding effort, then the stored procedure remains large.