To wrap this up I just want to cover some ground about when and when not to use this methodology. The short answer is that there are few reasons when it's good to go this route. What I've shown you in this guide has limitedgood uses. But where it is good, it's very good.

If your application is being used on multiple mediums (say both a web application and a desktop application) then this is a very good way of handling things. The problem when you are accessing the database from a variety of mediums is that each must implement the login algorithm on their own. And if your database should change and render that algorithm ineffective, you need to rewrite not one but every implementation. So if you have users utilizing your desktop application then you'd effectively give them a headache. It would need to be recompiled and redistributed. Using a stored procedure though means you can modify it on one place and it'll continue working everywhere.

There is no performance gain. But when done correctly there will not be a performance loss either. You should never be using stored routines to handle expensive processes to begin with.

Stored routines are great for simplifying the typical back-and-forth communication you do with MySQL. A common occurrence in PHP/MySQL applications is: SELECT data, change data, UPDATE data. A routine can be used to simplify this logic because it can handle the SELECT and UPDATE in one pass. As such a good routine has the potential to drastically clean up code that has a tenancy to be repeated.

Stored routines will not solve all of your querying needs though. In all cases but the few times where they're useful, you should stick to performing the logic inside your application.

So with that, we're done. My goal here was merely to introduce you to a tool that isn't commonly seen or even known about. It's not likely you'll end up using stored routines frequently, but hopefully you'll now know they're a potential tool for you to use should the need arise.