Are they useful for anything outside of a database administrator? If I understand them correctly it\'s merely queries that can be saved directly into MySQL, so it\'d be useless
Here are two good, simple advantages not covered in the other answers:
Added
They also reduce network chatter. If you have a lot of complex wueries to run, you can have them all in one stored procedure, and your app only needs to make one call to do all the work.
Also, in most platforms, stored procedures have performance benefits. In SQL Server, for example, the Database Engine optimizes and saves the executio plan to speed things up. these links also answer your question:
http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/
http://searchsqlserver.techtarget.com/news/1052737/Why-use-stored-procedures
And I can't take credit for this answer, but I think this quote is a good point, even though I consider myself to be pretty skilled on both sides of the equation - there is something to be said for specialized knowledge.
Advantage 4: Stored procedures are usually written by database developers/administrators. Persons holding these roles are usually more experienced in writing efficient queries and SQL statements. This frees the GUI application developers to utilize their skills on the functional and graphical presentation pieces of the application. If you have your people performing the tasks to which they are best suited, then you will ultimately produce a better overall application.
Stored procedures have lots of benefits. Among other things they help decouple application code from the database tables, simplify database maintenance and versioning and help take the best advantage of DBMS features such as query parameterisation, optimisation and security.
it'd be useless for any web development team to use them
Huh? Stored procedures are extremely useful for any developers who need to use a database that supports them.
Think of a stored procedures as a library function. Do you want to rewrite sqrt (for example) every time you have to compute a square root or would you rather call a function to do it?
That's the benefit (in a nutshell) of stored procedures.
Back in the 90's, stored procedures were the safest way to prevent anyone from accessing the data tables directly.
At first hand, they were more likely to counter security issues. Secondly, they were meant to be easier to work with the data, as there were no ORM tools as today's.
In the days, they are meant for complex transactions mainly. When I say complex, I mean something that cannot be solved with simple CRUD operations such as NHibernate or Entity Framework can do.
So, when a stored procedure only perform a SELECT
, an INSERT
, an UPDATE
or a DELETE
, you may be right that they are now useless somehow, as you can perform these basic repeated operations through an ORM tool. However, when you have to build a report, for instance, that requires desperate information data, and some other calculations performed, etc. and that the result is pretty complex to compute, then you better let the database engine work this out as it is designed to compute such data.
Let's say you insert two rows in different tables, the second insert requires the id from the first.
$sql = "INSERT INTO t1 (f1,f2...) VALUES (v1, v2...)";
mysql_query($sql, $conn);
$id = mysql_insert_id();
$sql2 = "INSERT INTO t2 (f1,f2,id,f3...) VALUES (v1,v2,$id,v3....);
mysql_query($sql2,$conn)l
You went to the database twice, two server request/response. If you can store the process of INSERT, @id=insert id, INSERT all on the server in my_proc, you only have to do so once.
$sql = "CALL my_proc(arguments)";
mysql_query($sql);
In addition to all the answers given here, i would also like to point out that stored procedures are a way to save the execution plan of a query.
you may have a set of SQL statements you just call from your application, but each time you execute the query SQL server has no way of knowing that the query you just invoked is the exact same query that as the one you called a few minutes ago (which would happen very frequently in a web application). So SQL server has to repeat the all the processing again (build the query plan and execute it).
Now if the same query had been encapsulated within a stored procedure, SQL server would have saved the execution plan for that stored procedure so that each time you call the sproc, it doesn't have to recompile the execution plan all the time. (It may even cache the data based on the parameters passed to the sproc, but i dont know exactly how this works)