An interesting post by a bloger made me……

I suppose it’s balanced on how long does it take to write and what speed enhancement will it allow you.

Thought Dan : http://www.thoughtden.co.uk

Linux Journal had an interesting feature on it.

The only point I didn’t totally agree on was the “Logic Fragmentation”, where they said tracking errors was harder. I’d say it makes it easier, in that the SP can be written, then a test harness written for the SP, tested to death, then, when it is finished, the resultant middle-tier class/routine can pick it up and run with it, in the knowledge that it is fully tested and working.

They are correct, in that you can’t debug SQL using a debugger in the middle tier, but they drew the wrong conclusion, in my opinion. If the SQL has been compartmentalised and thoroughly tested, it means that the error is either in the class, or in the parameters it is trying to pass over – and if the stored procedure is checking the parameters and returning the appropriate error codes when they are incorrect, it should make tracking down the problem easier…

I agree, classes and encapsulation of business logic, and a central point for queries makes the need for SPs less of a requirement – although load-balancing across a server farm could be a reason to use them, if you have a dozen servers handling requests and shunting traffic back and forth, if they need to filter through a result set, performing logic on it, that pure SQL can’t, then the network traffic between the load balancers and the database server(s) can be significant and breaking that logic out to a SP could significantly reduce load on the LBs and the internal network.

I think it is very much a case of looking at the size of the project, the number of predicted users, network traffic issues and number of client applications. Only once you have all of that information an you make a proper decision on whether SPs will be a benefit or not.

They aren’t a universal panacea, but they shouldn’t be dismissed out-of-hand.

For smaller scale projects, many of these benefits can be achieved using good object design, of course, and I’m as keen as you are on the black box approach because it means that once a class is working properly, it can then be left alone.

I’m certainly going to take a look at MySQL’s implementation. It’s simply been a non-starter until now but the time has come to see how version 5 goes about it.

Testing is also easier. You can test the SQL queries in isolation, knowing that they work 100% correctly. If you have code which is PHP calling a dynamic query, it can take more time trying to work out why the PHP code isn’t working, when the culprit is the query.

Likewise, changes to the database require hunting through the code on the front-end(s) to find all instances where a table or field is used and altering them. If they call through stored procedure, you only need to change the query once and everything should still work – unless it is a radical change, the input parameters to the stored procedure shouldn’t change and unless a field is removed from the output, no remedial action is immediately required on the front end code.

It also means that the front-end developers don’t need to know SQL, and the database developer doesn’t need to know PHP/ASP/Ruby/whatever. On a small team, or one-man-band, this isn’t so important, but on a large project, it means that each developer can concentrate on their own area of expertise.

The anaylst defines which information needs to pass between the two layers, and as long as both development teams stick to the definitions, they never need to interfere with each other. The “black box” approach can remove a lot of headaches.