Should I share temp tables across nested stored procedures?

Question

I am currently trying to clean up some stored procedures. There are about 20 of them that look very similar and do many of the same things, but take in slightly different parameters and filter data differently.

For the most part, all of the stored procs start by loading some data in to one or two table variables (which is generally where the procs differ). After that, all of the code for each sproc is more or less the same. They perform some logging and apply some additional common filters.

I wanted to at least turn the common pieces in to stored procs so that the code would be easier to read and we wouldn't have to open 20 procedures to update the same line of sql, but the use of table variables prevents it. We are using Sql Server 2005, and to my knowledge we cannot used table valued parameters in our stored procedures.

We could, however, change all of the table variables to temp tables and reference them in the new common stored procedures. I am assuming that is a fairly common practice, but wanted to know if it was actually a good idea.

In the nested stored procedures, should I assume that a temp table has already been created elsewhere and just query off of it? I can test whether or not the table exists, but what if it doesn't? Is there a good alternative to this in 2005? Is it confusing for other developers who open one of the nested stored procs and see a temp table that is created elsewhere? Do I just need to add lots of informative comments?

Answer 1

In your nested proc; to be sure, you can check whether table exist or not. If not exist then RAISERROR with some error message. Since, you are using SS2005, #temptable would be the option you have. Commenting your code for ease of readability is never a bad practice.

Talking about naming convention; follow any convention that fits better in your organization (I just gave a proper name to the SP that will reflect the purpose of the SP). If code changes is happening then changing the comment accordingly is the developer responsibility. Other than this, whatever you are doing looks correct to me.