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.
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.
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.
How is the performance of a Stored Procedure? Is it worth using them instead of implementing a complex query in a PHP/MySQL call?
Stored procedures will give you a small performance boost, but mostly they are for doing tasks that are difficult or impossible to do with a simple query. Stored procedures are great for simplifying access to data for many different types of clients. Database administrators love them because they control how the database is used as opposed to leaving those details to the developer.
Look to indexes and proper table design to get better performance.
Yikes I'd hate for someone to read these answers and get the wrong impression. There are some really important differences between the "Stored Whatever" implementations on "MySQL" vs "SQL server/Oracle".
See: http://www.joinfu.com/2010/05/mysql-stored-procedures-aint-all-that/
Every person that asks this question assumes something about MySQL’s
stored procedure implementation; they incorrectly believe that stored
procedures are compiled and stored in a global stored procedure cache,
similar to the stored procedure cache in Microsoft SQL Server[1] or
Oracle[2].
This is wrong. Flat-out incorrect.
Here is the truth: Every single connection to the MySQL server
maintains it’s own stored procedure cache.
Take a minute to read the rest of the article and comments. It's short and you'll have a much better understanding of the issues.
As was pointed out to me in a previous answer courtesy of JohnFX:
"The performance benefit of stored
procedures is dubious and minimal at
best. Some reading material on this
point:
http://statestreetgang.net/post/2008/04/My-Statement-on-Stored-Procedures.aspx
http://betav.com/blog/billva/2006/05/are_stored_procedures_faster_t.html
Enjoy.
Grossly simplified -
Stored procedure performance is equal to or marginally better than code at the cost of db server load. Since most db systems are concerned with multi-user access and are using commodity hardware for the db server, using code offloading the db server will probably win overall. With high end DB servers, > 4 cores, > 32gb ram, SP load is often not an issue.
Stored procedures;
transfer less data in the query - minimal speed improvement for well written code
parsing & caching is "slightly better" - minimal speed improvement for well written code
move the execution load to the db server vs. client(s) (web servers), potentially spreading the load over many systems. - speed improvements are very dependant on the actual code and amount of data including "excess" data transferred. Quite a bit of code transfers more data than is actually used (db libraries, poorly written queries, select *, etc.)
Don't optimize early.
Stored procedures have many other benefits than speed, security being high on the list.
In a single programmer environment, benefits may be offset by SP programming learning curve, SP testing framework, multiple methods of revision control - SP and code, etc..
Learning and using a testing and profiling framework will answer this definitively and will guide you in providing better "performance" to your app than simply choosing SP or ad-hoc queries.
Answer to "is it worth it" - If you don't have a testing/profiling framework in place you'll only be guessing. Any answer based on my code and hardware is probably irrelevant on yours.
My real world experience on many Perl/TCL/PHP/C web apps using DB's (Sybase,Oracle,MS SQL,MySQL,Postgres) stored procs DO NOT greatly improve performance over all. But I still use them often, just for other reasons than performance. They can greatly improve a specific complex query, but that's rarely the bulk of the code and overall processing time.
In MySQL or any other SQL server as MSSQL or Oracle, stored procedures increase dramatically the speed of the queries involved because this are already compiled. Stored procedures are more secure than direct queries and as object in the database they can be administered by the owner, giving the right access to each user.
Using stored procedures you can also hide the logic of the queries and procedures and give to the development team and other programmers a "black box" in wich they insert params and receive results.
Definitively stored procedures rocks!!!!
From MySQL 5.1 Documentation:
Stored routines can be particularly useful in certain situations:
When multiple client applications are written in different languages or work on different platforms, but need to perform the same database operations.
When security is paramount. Banks, for example, use stored procedures and functions for all common operations. This provides a consistent and secure environment, and routines can ensure that each operation is properly logged. In such a setup, applications and users would have no access to the database tables directly, but can only execute specific stored routines.
Stored routines can provide improved performance because less information needs to be sent between the server and the client. The tradeoff is that this does increase the load on the database server because more of the work is done on the server side and less is done on the client (application) side. Consider this if many client machines (such as Web servers) are serviced by only one or a few database servers.
Stored routines also allow you to have libraries of functions in the database server. This is a feature shared by modern application languages that allow such design internally (for example, by using classes). Using these client application language features is beneficial for the programmer even outside the scope of database use.
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.
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.