What are the benefits of creating Stored Procedures in SQL and MySQL?

Question

I have a theoretical question.

I can't see any difference between declaring a function within a PHP file and creating a stored procedure in a database that does the same thing.

Why would I want to create a stored procedure to, for example, return a list of all the Cities for a specific Country, when I can do that with a PHP function to query the database and it will have the same result?

What are the benefits of using stored procedures in this case? Or which is better? To use functions in PHP or stored procedures within the database? And what are the differences between the two?

Thank you.

Answer 1

Some benefits include:

• Maintainability: you can change the logic in the procedure without needing to edit app1, app2 and app3 calls.

• Security/Access Control: it's easier to worry about who can call a predefined procedure than it is to control who can access which tables or which table rows.

• Performance: if your app is not situated on the same server as your DB, and what you're doing involves multiple queries, using a procedure reduces the network overhead by involving a single call to the database, rather than as many calls as there are queries.

• Performance (2): a procedure's query plan is typically cached, allowing you to reuse it again and again without needing to re-prepare it.

(In the case of your particular example, the benefits are admittedly nil.)

Answer 2

Short answer would be if you want code to be portable, don't use stored procedures because if you will want at some point change database for example from MySQL to PostgreSQL you will have to update/port all stored procedures you have written.

On the other hand, sometimes you can achieve better performance results using stored procedures because all that code will run by database engine. You also can make situation worse if stored procedures will be used improperly.

I dont think that selecting country is very expensive operation. So I guess you don't have to use stored procedures for this case.

Answer 3

ok, this may be a little oversimplified (and possibly incomplete):

With a stored procedure:

1. you do not need to transmit the query to the database
2. the DBMS does not need to validate the query every time (validate in a sense of syntax, etc)
3. the DBMS does not need to optimize the query every time (remember, SQL is declarative, therefore, the DBMS has to generate an optimized query execution plan)

Answer 4

As most of the guys already explained it, but still i would try to reiterate in my own way

Stored Procedures :
Logic resides in the database.
Lets say some query which we need to execute, then we can do that either by :

• Sending the query to DataBase server from client, where it will be parsed, compiled and then executed.

• The other way is stationing the query at DataBase server and create an aliasing for the query, which client will use to send the request to database server and when recieved at server it will be executed.

  So we have :
  Client ----------------------------------------------------------> Server

  Conventional :
  Query created @Client ---------- then propagate to Server ----------Query : Reached server : Parse, Compiled , execute.

  Stored Procedures :
  Alias is Created, used by Client----------------then propogate to Server-------- Alias reached at Server : Parse,Compiled, Cached (for the first Time)
  Next time same alias comes up, execute the query executable directly.

  Advantages :

• Reduce Network Traffic : If client is sending a big query, and may be using the same query very frequently then every bit of the query is send to the network and hence which may increase the network traffic and unnecessary increase the network usage.

• Faster Query Execution : Since stored procedures are Parsed, Compiled at once, and the executable is cached in the Database. Therefore if same query is repeated multiple times then Database directly executes the executable and hence Time is saved in Parse,Compile etc. This is good if query is used frequently. If query is not used frequently, then it might not be good, because storing cached executable takes space, why to put Load on Database unnecessarily.

• Modular : If multiple applications wants to use the same query, then with traditional way you are duplicating code unnecessarily at applications, the best way is to put the code close to Database, this way duplication can be alleviated easily.

• Security : Stored procedures are also developed, keeping in mind about Authorization(means who is privileged to run the query and who is not).So for a specific user you can grant permissions, to others you as DBA can revoke the permission. So its a good way as a point wrt to DBAs a DBA you can know who are right persons to get the access.But such things are not that popular now, you can design your Application Database such that only authorized person can access it and not all. So if you have only Security/Authorization as the point to use Stored Procedures instead of Conventional way of doing things, then Stored procedure might not be appropriate.