If you are using php5 and mysql5, is there a substantial advantage to using stored procs over prepared statements? ( i read somewhere you may not get substantial performance gains from mysql5 stored proc)
They are not really the same thing - with stored procedures, your database logic resides inside the database. Prepared statements basically avoid re-parsing queries if they are called multiple times - the performance benefit can vary greatly.
The choice to use one or the other is really dependent on your specific situation. I don't really use stored procs anymore as I like having all of my logic in one place.
Stored procedures make sense for professional-grade (IE enterprise-grade) applications where you:
Want to allow your database engineer to optimize queries for performance
Want to abstract complexity of queries to simple API's
WANT your logic distributed, because some of what happens in the database might be intellectual property that you don't want to expose to other parties
WANT your logic distributed, because that is the nature of distributed, n-tier computing
you might want the database engineer or DBA to modify schema without modifying application code (stored procs, by virtue of providing API's, provide a layer of abstraction)
There are other reasons.
Prepared statements are better for work done within a session. But if you are taking the time to create a prepared statement, you have essentially done everything necessary to create a stored procedure. The difference is that the stored procedure is available across multiple sessions (subject to GRANTS in the database).
What I can not figure out is that if you have the option for stored proc vs. prepared statement, why you would bother with prepared statements. Most of the SP vs PS discussions seem to focus on what the differences are between them, not on why to use one vs the other. That always appears to boil down to "depends on what you are trying to do." But I haven't seen a well organized description of: use a proc if you need VS use a statement if you need....
Some advantages of stored procedures:
Portable between languages
Arguably simplified interface and sometimes performance gains for
complex queries and especially multi-query
transactions (test!)
By exposing an interface rather than
tables, can be used to improve
security and integrity
Some disadvantages of stored procedures:
Puts business logic into the database - complicates design, extra place to track for
version control and troubleshooting
Performance losses in some
situations (test!)
Less portable between databases
I don't think a single generalized answer exists for this question because there are pros and cons depending on the situation. If you follow principles like simplicity, DRY, testing, and avoiding premature optimization, you're likely to end up fine.
May not be the case or worthwhile to mention here, but stored procedures also are "portable" in the case that they're language-agnostic. You can call the same stored procedures on your database from within, say, Java as you would with PHP. Because the procedures reside in the database, anything with access to the database can query them the same way.
The substantial advantage of stored procedures is that your data does not cross a layer (in this case it would be the PHP/MySQL layer) before logic can be applied to it. Some queries may require several select statements, which is slower done through PHP than within MySQL.
Now, as tobyhede points out, it is good to have all logic in one place. But I have worked on projects where it was simply unrealistic to query the required data using PHP; it had to be done through a stored procedure.
I will start by saying that I do not like the idea of stored procedures, I' rather go the prepared statements route. In this particular case I think you are also comparing apples with oranges...they both there to full fill different functions....
I will only consider stored procedure if the application is 95% database driven only then does it make sense to have some of the logic in the db.
Not familiar with php, but in general stored procedures are already "compiled" so may produce marginally faster performance over an sql statement.
Though my preference usually to stick with SQL from code management/deployment and unit testing perspective.
Related
When I first got into databases I was using SQL Server. I got into that originally with classic ASP. One of the big things we were told was that you saved a LOT of time in your SQL transactions if you used stored procedures, rather than working with the ASP SQL commands (doing it "in line", I suppose). So almost everything I ever wanted to do with the database I wrote a stored procedure for, and then called the stored procedure from my code.
Anyway, fast forward several years and I'm now doing all of my work with PHP and MySQL (and a little Python). One thing that I don't seem to see much of at all is people using stored procedures/functions, so I haven't really been worrying about it.
However, it occurs to me that I'm just doing it wrong and don't realize it. Is there a major advantage to using stored functions in MySQL? I'm building a fairly good-sized website that handles a lot of calls to the database. The calls are all done in-line with my PHP code. Would I be better off using stored functions for the calls that I'm making consistently, and then just passing variables to the function from the PHP?
Well that depends. Stored procedures are a way to handle functional decomposition and can be absolutely essential if you have multiple applications interacting with the same database. The idea of using stored procures for everything was on the ascendancy a couple of years ago and as the world has moved to a service/RAD world they are losing some ground.
Some of the benefits of stored procedures are
Reuse / This can certainly be accomplished within your code base but it beats the hell out of writing the same query with 10 sub joins 15 times
Security - when sp were the rage sql injection attacks were coming to the for front and one way to reduce your exposure is to offer parameterized sp that sanitize you input automatically for the most case
Documentation by definition on really large databases table layout is not always sufficient to explain what you are storing and why and have SP sometimes gives you and those that come after you what was intended
A defined interface.
I think that all of these pros can be provided assuming good application design and only make scene to a degree on projects of some scale.
Some cons
Redundant functionality - I have seen a lot of shops where business and crud logic is spread in the application and business logic is in the database.
Lack of configuration management on SPs -- While there are established procedures and tools for code SP management lags far behind.
This is the same question as asking, "Should I break up my code into methods/functions/procedures and call them or should I code everything into my current function?"
Some of the advantages that stored procedures give you:
Easier testing. You can test the stored procedures without running the app.
Easier development. You can have a DB developer write the stored procedures and a GUI developer write the UI, etc.
Easier porting to a different database. The changes are all contained in the database and the contract with the app (The parameters passed to the stored procedures) should not change.
The ability to use the logic in the stored procedure from multiple front ends. You do not have to code the same customer create logic in every app that needs to create a new customer.
The big downside is that you have to learn multiple diciplines and probably use multiple tools. This is one of the big reasons for using Linq for SQL in .Net. You do not have to learn SQL and everything is contained in the .Net code.
We use stored procedures for everything. It works exceptionally well. Abstraction is your friend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been writing asp.net apps with SQL Server back ends for the past 10 years. During that time, I have also written some PHP apps, but not many.
I'm going to be porting some of my asp.net apps to PHP and have run into a bit of an issue. In the Asp.net world, it's generally understood that when accessing any databases, using views or stored procedures is the preferred way of doing so.
I've been reading some PHP/MySQL books and I'm beginning to get the impression that utilizing stored procedures in MySQL is not advisable. I hesitate in using that word, advisable, but that's just the feeling I get.
So, the advice I'm looking for is basically, am I right or wrong? Do PHP developers use stored procedures at all? Or, is it something that is shunned?
Whether to use Stored Procedures or not is more of a religious or political discussion at a bar than not.
What needs to be done is clearly define your application layers and not step over those boundaries. Stored procedures have several advantages and disadvantages over doing queries outside of the database.
Advantage 1: Stored procedures are modular. This is a good thing from a maintenance standpoint. When query trouble arises in your application, you would likely agree that it is much easier to troubleshoot a stored procedure than an embedded query buried within many lines of GUI code.
Advantage 2: Stored procedures are tunable. By having procedures that handle the database work for your interface, you eliminate the need to modify the GUI source code to improve a query's performance. Changes can be made to the stored procedures--in terms of join methods, differing tables, etc.--that are transparent to the front-end interface.
Advantage 3: Stored procedures abstract or separate server-side functions from the client-side. It is much easier to code a GUI application to call a procedure than to build a query through the GUI code.
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.
With all that in mind there are several disadvantages.
Disadvantage 1:
Applications that involve extensive business logic and processing could place an excessive load on the server if the logic was implemented entirely in stored procedures. Examples of this type of processing include data transfers, data traversals, data transformations and intensive computational operations. You should move this type of processing to business process or data access logic components, which are a more scalable resource than your database server.
Disadvantage 2:
Do not put all of your business logic into stored procedures. Maintenance and the agility of your application becomes an issue when you must modify business logic in Sp language. For example, ISV applications that support multiple RDBMS should not need to maintain separate stored procedures for each system.
Disadvantage 3:
Writing and maintaining stored procedures is most often a specialized skill set that not all developers possess. This situation may introduce bottlenecks in the project development schedule.
I have probably missed some advantages and disadvantages, feel free to comment.
Could also be because MySQL didn't get stored procedures until version 5. If you use prepared statement you should be okay...just don't use inline SQL
A couple of years ago I ended up writing a fair amount (~3K lines) of stored procedure code for a PHP/MySQL project. In my experience:
MySQL stored procedures probably aren't going to help you performance-wise.
Executing SPs through prepared statements with MySQLi can cause headaches.
It can be hard to abstract out common patterns—I found myself repeating myself more than I liked.
Depending on the MySQL version and configuration, you might need SUPER privileges to create SPs.
If you're porting code that uses stored procedures, it might be easiest to keep them. It's certainly possible to use them with PHP and MySQL, and I wouldn't personally call it inadvisable, exactly. I just probably wouldn't choose to use them again if I were starting a new PHP project from scratch.
In general, I very much dislike stored procedures because:
It's too easy to slip in business logic that shouldn't be there.
Updates to the application that require updates to your stored procedures is a pain to synchronize, especially if you have to revert to a previous build.
For any database manipulation, I recommend going with a PHP ORM framework like http://www.doctrine-project.org or a framework that includes ORM like CakePHP. You'll have an added bonus of being able to more easily switch between SQL Server and MySQL.
Stored procedures are -- often -- a complete waste of effort.
When in doubt, actually measure the performance. You'll often find that stored procedures add complexity for no recognizable benefit. You may have no performance enhancement from your SP's.
Some folks think they're very "Important". It's essential to actually measure performance rather than quibble or debate.
Many (most?) webapps use a database abstraction layer to take care of injection vulnerabilities/etc.
If you want one for your own app, take a look at PDO. Here is a big tutorial about how to use it:
http://www.devshed.com/c/a/PHP/Using-PDO-Objects-in-PHP-5/
What about SQL injection ?
Procedures allow you to do parameter invocation on the WHERE clause, reducing injection hazards
Here is a balanced and informed article on stored procedures in MySQL: http://www.linuxjournal.com/article/9652?page=0,0
To dismiss them out of hand as a "waste of time" or "hard to maintain" or "providing no real benefit" in any database and application of significant size would be very unwise.
I'm working on what is turning out to be a fairly complex SELECT query. I have several hierarchical queries being nested in a single SELECT and it is getting to be quite difficult to manage.
I'm running into a few places where my inline views need to be executed in more than one place, so it seems like a reasonable idea to execute those once at the beginning of a stored procedure and then do some iteration over the results as needed.
I'm wondering if there are any reasons why I should not, or could not, execute an Oracle Stored Procedure, called via my PHP code, and return as an OUT parameter the resultset. I've tended to use SPs only to do updates/deletes/inserts but the sheer size and complexity of this query seems like it needs to be broken down.
If there aren't any technical problems with this, any comments on whether it is good or bad practice?
Im working on what is turning out to be a fairly complex SELECT query. I have several hierarchical queries being nested in a single SELECT and it is getting to be quite difficult to manage.
Ok, but why a stored procedure? Why not create a view instead?
I'm running into a few places where my inline views need to be executed in more than one place, so it seems like a reasonable idea to execute those once at the beginning of a stored procedure and then do some iteration over the results as needed.
Again - excellent use case for a view.
I'm wondering if there are any reasons why I should not, or could not, execute an Oracle Stored Procedure, called via my PHP code, and return as an OUT parameter the resultset.
If there aren't any technical problems with this, any comments on whether it is good or bad practice?
Well, I don't want to start a religous war, and I do not want to suggest the arguments against apply to your case. But here goes:
one reason why I tend to avoid stored procedures is portability - by that I mean mostly database portability. Stored procedure languages are notoriously unportable across dbs, and built-in libs like Oracle packages make things worse in that respect.
stored procedures take some additional processing power from your database server. this makes it harder to scale the application as a whole: if the capacity of your db server is exhausted due to stored procedures, and you need to upgrade harware or even buy an extra oracle software license because of that, I would not be a happy camper, especially if I could have bought cheap webserver/php boxes instead to do the computing.
Reasons where I would go for stored procedures:
language portability. If database portability is not so much an issue, but you do want to reuse logic across multiple applications, or have to ability to code in different languages, then stored procedures may save you writing language specific database invocation code.
complex permission scenarios. stored procedures give you uan extra level of permissions, since you can execute the procedure with the privileges of the definer or owner of the stored procedure. Sometimes this solves problems where a user needs to work with some tables, but cannot be allowed direct access to them.
saving rountrips: if you have to deal with complex, multistatement transactions, putting them in a stored procedures saves rountrips between the app and the db, because there is only one rountrip needed to execute the stored procedure. sometimes this can get you more performance.
I want to stress again that in all these scenarios, I would still advise to not put all your procedural logic in stored procedures. databases are best at storing and retrieving data, languages like php/java/perl/pick your poison are better at processing it.
If you are using the same inline view many times, its a good candidate for with clause
PHP can handle resultsets returned from stored procedures, by using Ref Cusrors. The Oracle+PHP Cookbook has an example.
So there are no technical impediments but as you can see from the various answers there are some philosophical aspects to your question. I think we can agree that if you are already wrapping some SQL statements in stored procedures - which you are - then you are not drastically compromising the portability of your system by extending "updates/deletes/inserts" to include selects.
The pertinent question then becomes "should you embed use a stored procedure for this particular query?" The answer to which hinges on precisely what you mean by:
the sheer size and complexity of this
query seems like it needs to be broken
down.
Deconstructing a big query into several smaller queries and then stitching results together in PL/SQL is seductive, but should be approached with caution. This can degrade the performance of your application, because PL/SQL has more overheads than SQL. Making your query more readable is not a good enough reason: you need to be certain that the complexity has a real and adverse effect on the running of your code.
A good reason for using a stored procedure rather than a view might be if you want to extend the applicability of the query by using bind variables or dynamic SQL in the body of the query.
A definitive answer to your question requires more details regarding the nature of your query and the techniques you are thinking of using to simplify it.
You could look at subquery factoring which may improve the readability of the query.
One risk of breaking up a single SQL query into a more procedural solution is you lose read consistency. As such you want to be pretty sure that someone changing data while your procedure runs won't break it. You may want to lock a table fore the duration of the procedure call. It seems drastic, but if you are pretty sure that the data is static and if there would be ugly side-effects if it wasn't, then it is a solution.
Generally if an SQL statement is complex enough, it probably isn't portable between databases anyway, so I wouldn't worry about that aspect.
Views can be a good option to hide complexity, but the downside to hiding complexity is that people start doing things that seem 'simple' but are really complex and don't work as desired. You also get another object to consider for grants etc. [Edit: As Roland commented, this applies equally to stored procedures, views, object types etc.]
If you expect to return a large resultset, you should consider a pipelined table function. That way you can avoid having the entire resultset in the Oracle session at the same time.
I'm working on a PHP web application with PostgreSQL. All of the SQL queries are being called from the PHP code. I've seen no Views, Functions or Stored Procedures. From what I've learned, it's always better to use these database subroutines since they are stored in the database with the advantages:
Encapsulation
Abstraction
Access rights (limited to DB Admin) and responsibility
Avoid compilation
I think I read something about performance improvements too. I really don't see why the team hasn't used these yet. In this particular case, I would like to know, from experience, is there any good reason to NOT use them?
Mostly when there are so many "SELECT" queries along the code, why not use Views?
I am planning on refactoring the code and start coding the subroutines on the DB Server. I would like to know opinions in favor or against this. The project is rather big (many tables), and expects lots of data to be stored. The amount of data you would have in a social network with some more stuff in it, so yeah, pretty big.
In my opinion, views and stored procedures are usually just extra trouble with little benefit.
I have written and worked with a bunch of different web apps, though none with bazillions of users. The ones with stored procedures are awkward. The ones with ad-hoc SQL queries are plenty fast (use placeholders and other best practices to avoid SQL injection). My favorite use database abstraction (ORM) so your code deals with PHP classes and objects rather than directly with the database. I have increasingly been turning to the symfony framework for that.
Also: in general you should not optimize for performance prematurely. Optimize for good fast development now (no stored procedures). After it's working, benchmark your app, find the bottlenecks, and optimize them. You just waste time and make complexity when you try to optimize from the start.
I. Views offer encapsulation, but if not carefully designed they can slow down the application. Use with caution.
II. Use functions if needed, no reason to put them in if they are unneeded.
III. Stored Procedures are a godsend, use them everywhere there is a static query!!
In response to the views vs. queries, try to use views with Stored Procedure's, the Stored Procedure's will mitigate some of the performance hit taken with most views.
The advantage of stored procedures is that, because all the processing is done on the database, you do not incur network overhead shunting intermediate result sets back and forth.
The disadvantage is that each RDBMS system out there has its own peculiar syntax for stored procedures. By implementing your business logic in stored procedures, you're pretty much restricting your app to a single database product, something you need to keep in mind if you intend your application to be database independent. Also, as gahooa pointed out, because stored procedures live in the database, your access to them as a developer may be restricted by local policy; some organisations will only let DBAs touch the database.
#WolfmanDragon: I don't know if views inherently make things slower; your mileage may vary, I guess, depending on the complexity of the view and the RDBMS you're using. Plus, some RDBMS allow you to materialise commonly-used views so access to them is as fast as a base table.
We try to use the features you mentioned only where there is a significant benefit
Being part of the "Database", they fall under "schema changes", rather than "source code changes", and are naturally harder to version control.
Whatever you do, just make sure you retain full visibility of who-changed-what-when, so that you can diff, rollback, and recover in the case of problems.
I'm quoting part of an answer which I received for another question of mine:
In the PHP/MySQL world I would say
stored procedures are no-go
I would like to know: Is that so? Why? Why not?
[edit]I mean this as a general question without a specific need in mind[/edit]
I develop and maintain a large PHP/MySQL application. Here is my experience with stored procedures.
Over time our application has grown very complex. And with all the logic on the php side, some operations would query the database with over 100 short queries.
MySQL is so quick that the performance was still acceptable, but not great.
We made the decision in our latest version of the software to move some of the logic to stored procedures for complex operations.
We did achieve a significant performance gain due to the fact that we did not have to send data back and forth between PHP and MySQL.
I do agree with the other posters here that PL/SQL is not a modern language and is difficult to debug.
Bottom Line: Stored Procedures are a great tool for certain situations. But I would not recommend using them unless you have a good reason. For simple applications, stored procedures are not worth the hassle.
When using stored procedures with MySQL, you will often need to use the mysqli interface in PHP and not the regular mysql interface.
The reason for this is due to the fact that the stored procedures often will return more than 1 result set. If it does, the mysql API can not handle it and will you get errors.
The mysqli interface has functions to handling these multiple result sets, functions such as mysqli_more_results and mysqli_next_result.
Keep in mind that if you return any result set at all from the stored procedure, then you need to use these APIs, as the stored procedure generates 1 result set for the actual execution, and then 1 additional one for each result set intentionally returned from the stored procedure.
I generally stay away from stored procedures because it adds load to the database which is 99% of the time, your biggest bottleneck. Adding a new php server is nothing compared to making your MySQL db replicate.
Do you have a specific need in mind which makes you consider them? Stored procedures are much less portable than "plain" SQL, that's usually why people don't want to use them. Also, having written a fair share of PL/SQL, I must say that the procedural way of writing code adds complexity and it's just not very modern or testable. They might be handy in some special cases where you need to optimize, but I'd certainly think twice. Jeff has similar opinions.
This is a subjective question.
I would personally include all calculations within PHP and only really use MySQL as a table.
But, If you feel that it is easier to use stored procedures then by all means, go ahead and do it.
There's possibly a phobia of stored procedures with mysql, partly due to not being overwhelmingly powerful ( compared to Postgresql and even MSSQL, mysqls stored procedures are greatly lacking ).
On the plus: They make interfacing with it from more than one language easier.
If somebody states that "using stored procedures is bad because its not portable to different databases" then this of course means they think you're likely to switch databases, which means they in turn saying they think you shouldn't be using mysql.
It is popular to use ORM's these days, but I personally think ORM is a BadThing (Question:82882)
I would not say "stored procedures are a no-go", I would say "Don't use them without a good reason".
MySQL stored procedures have a particularly horrible syntax (Oracle and MSSQL are pretty awful too), maintaining them just complicates your application.
Do use a stored procedure if you have a real (measurable) reason to do so, otherwise don't. That's my opinion anyway.
I think that using stored procedures can offer some abstraction in certain applications, as in any where you would use the same SQL code chunk to update or add the same data, you could then create the one sproc save_user($attr.....) rather that repeating yourself all over the place.
Agreed the syntax is hairy and if your used to MSSQL and oracle sprocs there are differences that can fustrate.
You should also be aware that stored procedures were not supported in Mysql before version 5.0. http://dev.mysql.com/doc/refman/5.0/en/stored-routines.html Also stored procedures tended to be be a bit weird in that implementation. Now that Mysql 5.1 is starting to crop up in the wild I see more use of stored procedures with Mysql.
I make limited use of stored procedures, and it works well. I am the lead dev for one of my companies clients, working on their e-comm website. The client has a stock system, we implemented a set of stored procedures on their system and built an API to communicate with it. This allowed us to abstract their database and they could implement logic in the stored procedures. Simple but met the business requirement very well.