On the SitePoint PHP blog there's a new tutorial showing how to use cursors in MySQL stored procedures via PHP. A cursor is a piece of functionality that lets you work with the data in the data found by the stored procedure.

With cursors, we can traverse a dataset and manipulate each record to accomplish certain tasks. When such an operation on a record can also be done in the PHP layer, it saves data transfer amounts as we can just return the processed aggregation/statistical result back to the PHP layer (thus eliminating the select – foreach – manipulation process at the client side).

He provides a more real-world situation to help illustrate their use - working with information about the Lakers basketball team. He includes an example of a stored procedure to find a "streak" of games that they've won (yearly too). A quick PHP script is included showing how to call the stored procedure and fetch the data. The PHP doesn't directly use the cursor, it's self-contained inside the stored procedure.

The SitePoint PHP blog has a new post today from Taylor Ren looking at the use of stored procedures in MySQL via PHP. He goes through some of the basics - advantages and disadvantages - but also provides some simple examples.

Put simply, a Stored Procedure ("SP") is a procedure (written in SQL and other control statements) stored in a database which can be called by the database engine and connected programming languages. In this tutorial, we will see how to create an SP in MySQL and execute it in MySQL server and in PHP. [...] SP are also available in other common database servers (Postgre for example) so what we will discuss here can be applied to those as well.

He starts off with some reasons why using stored procedures is recommended (in certain cases) and what they can do to help your application. He also lists a few drawbacks to their use, including that they're hard to version/backup. He shows you how to create a simple stored procedure for a "salary" table that selects the average (using "avg") salary and returns it to a "avg_sal" variable. He includes the full PHP code you'll need and the SQL to make it all work.

Ulf Wendel has a new post today with details on using stored procedures with mysqli - not overly difficult if you know how to handle the IN, OUT and INOUT parameters. He includes a few code examples showing how to use them.

Out of curiosity I asked another friend, a team lead, how things where going with their PHP MySQL project, for which they had planned to have most of their business logic in stored procedures. I got an email in reply stating something along the lines: "Our developers found that mysqli does not support stored procedures correctly. We use PDO.". Well, the existing documentation from PHP 5.0 times is not stellar, I confess. But still, that’s a bit too much... it ain’t that difficult. And, it works.

He describes the three parameters (IN, OUT and INOUT) and gives some examples of setting/getting them from your SQL statements. They're all still set up using the query method on your connection as well as handling the result sets that come back and working with prepared statements.

Gonzalo Ayuso has posted the results of some testing he's done in using stored procedures in a PHP application. He compares the run time of two different scripts, one using prepared statements and one without, to see which would perform better in the long run.

Last week I had an interesting conversation on twitter about the usage of stored procedures in databases. Someone told stored procedure are evil. I'm not agree with that. Stored procedures are a great place to store business logic. In this post I'm going to test the performance of a small piece of code using stored procedures and using only PHP code.

In the end, the results showed that the stored procedures method was actually faster and used a bit less memory than the normal "plain PHP" method. It can be a bit more difficult to use than just a SQL statement in a string (properly escaped, of course) but can be worth the extra hassle when you need that performance boost.

Brian Swan has a new post answering a question he's gotten about the stored procedures that the SQL Server database includes and whether or not they help prevent SQL injections in your applications.

When I’ve asked people about their strategies for preventing SQL injection, one response is sometimes "I use stored procedures." But, stored procedures do not, by themselves, necessarily protect against SQL injection. The usefulness of a stored procedure as a protective measure has everything to do with how the stored procedure is written. Write a stored procedure one way, and you can prevent SQL Injection. Write it another way, and you are still vulnerable.

The short answer is "not always" but he gets into a more detailed answer with a sample login script and the SQL to create the stored procedure the "wrong way" (using the value dynamically in the SQL of the procedure) and the "right way" (assigning them directly like bound variables).

The Utah PHP Users Group has posted a new announcement already about their March meeting to be held on the 16th.

This time, the topic is still a bit up in the air and they request that those attening vote on one of two - either "Ajax tools in Eclipse" or "postgresql + stored procedures" - but from Ray Hunter. The meeting will be in the usual place, the Linux Networx offices, and will get going around 7pm.

For more details on the group and this meeting, check out their website.

The Utah PHP Users Group has posted a new announcement already about their March meeting to be held on the 16th.

This time, the topic is still a bit up in the air and they request that those attening vote on one of two - either "Ajax tools in Eclipse" or "postgresql + stored procedures" - but from Ray Hunter. The meeting will be in the usual place, the Linux Networx offices, and will get going around 7pm.

For more details on the group and this meeting, check out their website.