Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I've just started writing a Stored Procedure in SQL Server 2008 and have 30+ parameters. I've never written one with more than ~10 parameters, and that got me thinking... At what point are there too many parameters?

For context... This procedure will essentially INSERT a single row into a single Table. There would also be a very similar; albeit somewhat smaller; version that performs an UPDATE on the same table. Most fields are relatively small with a mix of int and strings (varchar(200)).

What are the issues; good or bad; to having a procedure with a large number of parameters and what is the threshold where I should start considering other patterns?

share|improve this question
1  
Is exactly like 'if you have to ask the price, you can't afford it'. If you start to wonder how many parameters are too many, you have too many. The main issue is not the engine, but you, the human reader/maintainer of the code. So I'd say is OK to have as many as possible in automatically generated code, but keep it reasonable in hand written/maintained code. –  Remus Rusanu Feb 1 '12 at 2:14

2 Answers 2

up vote 12 down vote accepted

Issues? I'd argue none.

  • The limit is 2100 parameters. IIRC it has been 2100 since SQL2000 but a documentation error suggested it was 1024.
  • If a table has 1000 columns (due to a Sharepoint-esque sparse column arrangement for example) and you are enforcing access via stored procedures, your insert proc may have 1000 parameters. Nothing wrong with that.
  • Do pause to review the schema when you encounter a wide table (not that 30 is particularly wide). It's not uncommon to find tables that started off life normalized but through laziness and/or fecklessness have expanded beyond recognition.
  • Don't even briefly consider passing a set of parameters as a CSV list or XML. Blinds the query optimiser and saves little to no time or effort.
  • Don't hand crank the client code to call a procedure with a large number of parameters. Code generation tools like T4 templates or CodeSmith to the rescue.
share|improve this answer
2  
+1 thanks for parameters as XML –  garik Feb 1 '12 at 9:04
1  
Thanks for this answer, it was very nicely stated. This answers my question perfectly. It's just too bad they don't have a badge for the use of great Scrabble words like "fecklessness" –  JoeGeeky Feb 1 '12 at 19:58

Joe Celko is an advocate of long parameter lists, which he writes about in detail in this two-part article:

The simplest answer is to use a long parameter list to construct lists and derived tables inside the procedure body. SQL server can handle up to 2100 parameters, which should be more than enough for practical purposes. SQL Server is actually a wimp in this regard; DB2 ;can pass 32K parameters. and Oracle can have 64K parameters.

...the long parameter list is made up of plain old parameters, which means that they can be used for outputs as well as inputs. It also is contained in one statement for the optimizer to use.

Do I think these techniques will always be the best solution? Of course not. There is no such thing in SQL. But it is worth looking at when you get an appropriate problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.