I think some comments here are missing the point.

The question is not whether it is a good idea to use stored procedures, the question is, is it a good idea to have four completely trivial stored procs for every situation where an application needs to access the database.

Maybe I'm old-school, but I see the completely meaningless repetition of a data structure with trivial functionality as a complete waste of time and a huge maintenance burden.

I've always written parameterised SQL statements for simple table CRUD operations, and I've actively weeded out trivial sprocs when some contractor has used 'best practice' and incuded them.

They are a complete waste of space.

The only time it is excusable is when the sprocs are auto-generated.

Of course when the operation is non-trivial, if you want wrapping for future development, then get on your sproc boots and fire away. The principle is, 'if there's a good chance you'll never need it, then don't do it until you do need it'.

Even then, there is a good argument for doing the wrapping in your ORM layer rather than in the DB using sprocs. Depends entirely on circumstances.

Much of your ORM layer should be autogenerated nowadays, too.

Ben McIntyre