|
|
In the previous chapter, you saw how you can store a SQL query in a Relational Database Management System (RDBMS) as a view, making it easy to access complex, shaped data without having to use a lengthy query. Stored procedures fulfill a similar role but do so in a much more powerful way. With stored procedures, you're not limited to queries or even single statements. A single stored procedure could add a record, modify some data, perform some calculation or other, and return some data—all with a single command from the user. Unfortunately, they can't make you dinner and record Buffy while you're out shopping, but they're pretty useful nevertheless.
Effectively, what you're doing when you create a stored procedure is creating a function, complete with input and output parameters, that you can call in the same way as you execute a standard SQL statement, simply by telling the RDBMS to execute it and sitting back while it gets on with it. A stored procedure itself contains one or more SQL statements that are processed as part of the stored procedure execution. However, when a stored procedure is processed, you have access to additional functionality, such as controlling the flow of execution with loops and conditional execution, which can provide enormous benefits.
There is, however, one problem when it comes to stored procedures. Unfortunately, pretty much every RDBMS does things its own way. Although the basic ideas are the same across systems, the way they're implemented isn't. You'll examine these differences as you work through this chapter.
| Note |
At the time of this writing, stored procedures aren't supported in the latest version of MySQL. However, support for stored procedures is planned for a future version. |
|
|