The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.


Who thinks 50 parameters in a stored proc is pure madness, please let me know...
Thursday, July 19, 2007
Yup.  Welcome to the 1960's, when we didn't know what "Coupling" and "Cohesion" was, when "COMMON" blocks made EVERYTHING global, and putting 50 parameters in a Local Procedure was the only way to do it.

If it can't be justified (and I'll allow that it COULD be justified.  Once.) then it's crying out for refactoring into something simpler.
Thursday, July 19, 2007
Sorry, not Local Procedure, but Stored Procedure.
Thursday, July 19, 2007
50 parameters?  How many lines is it??
Thursday, July 19, 2007
50 parameters doesn't scream bad design to me. I've worked on many projects that use SPs for all CRUD operations. Some of the SPs for inserts and updates go way over 50 parameters. Tools like NHibernate, that use parameterized queries (anonymous stored procs?), go well over 50 parameters as well.

There is no absolute rule on the correct number of parameters. If there are 50 parameters on a stored proc that does an insert, then I wouldn't worry. If it is 50 parameters and each one uniquely changes the flow of execution, then that would make me worry (although 50 parameters is just a symptom of the issue and not the issue itself).

Caveat - I use SQL Server, so the number or parameters my be a bigger issue on a different RDBMS.

Thursday, July 19, 2007
I know, I know. The problem is somewhere else. It takes every single one of them, performs zillion stupid db non-related checks, calls all kinds of string manipulating crappy SPs and then finally inserts the thing into a table.
It's screaming for refactoring.
Thursday, July 19, 2007
At least some of those parameters must be logically associated with each other, so group them into little objects.
DJ Clayworth
Thursday, July 19, 2007
Is it slow? If so, then refactoring may be a way to go.
My first boss (from 80s) used to say:
1. Do not fix it, if it ain't broken.
2. The best is an enemy of the good.
asmguru62 Send private email
Thursday, July 19, 2007
I concur: madness.

Fifty parameters is just way too many for the human brain to keep in mind all at once. Imagine if you had to match fifty keys on a ring to fifty locks on your front door to get into your house!

Refactoring is the right approach here. You can start by determining every place from which the stored procedure is called, and determining if all 50 paramaters are always relevant.

Good luck.
Robby Slaughter Send private email
Friday, July 20, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz