I have 15 stored procedures that return data from a common table and then join that table with a specific table to retrieve inventory.
Example:
Commo
I would save them each as a distinct stored procedure.
As much as possible, I like to keep my stored procedures bare and simple. They're hard enough to grok with a glance, because the expressions stretch out so much anyway, and adding a bunch of procedural code intermingled with the fragments of declarative code just makes it more difficult.
You're either going to end up with a list of 15 invocations of a more complex stored procedure with parameters, or you're going to end up with an equivalent list of simpler stored procedures. And if your parameter is a table name, it won't be the kind of parameterized sp that executes efficiently. As for the table driven approach, it is still the less efficient and more dangerous dynamic stored procedure. The table entries are as likely to be mis-entered, except in a table, any table-name errors would be even less visible. And coupling has gone up, and gohesiveness has gone down (both headed in the wrong direction).