Why do we use PHP with an HTML web page? Lots of reasons, but data access is one of the most important, and PHP Data Objects (PDO) is, for me, the best way to do that.
And increasingly, on the IBM i, we are being introduced to—and find reasons to use—more and more of these languages. Each has its own list of things that it does well and things that it doesn’t.
Ta-da! (PHP enters stage left, looking heroic yet humble).
Fortunately, PHP is a server-side language and one that is ideally suited to doing data access types of activity.
A brief aside at this point. If you’re building an app on your i that interfaces with the web, you don’t have to do the data access portion with PHP (or any other web language). If you build your app in a Model-View-Controller (MVC) fashion, then you could write the Model part (the one that contains the data access routines) in RPG and avoid having any data access in the PHP portion. You would still need PHP to wrap up the HTML5 that’s used for the View, but you wouldn’t have to use it for data access. But you might just as well decide to develop your app entirely in PHP or do the Model part using PHP, in which case you would need the data access ability. Just wanted to make sure that was clear. Lots of decisions to make. Anyway, sorry to digress. Carry on.
PHP Database Access
Unlike RPG, where we tend to use only one database, things are much more wide open in the web world, where we might use a wide variety of databases. Each one is different, of course, so a single set of I/O-type routines will not work. We need something that’s tuned for an individual database.
Of course, MySQL is one of the more common databases used with any web language, and PHP certainly supports the ability to access a MySQL database with actually two API sets.
The first is mysql_*. This is a very simple API with operations like mysql_connect, mysql_fetch, etc. Its advantages are that it’s easy to use and very well-known, so it’s easy to find folks who are familiar with it.
It does have its disadvantages, of course, and a newer API to access MySQL databases has been added to PHP: mysqli_* (mysql Improved). The result is that while mysql_* has not been officially deprecated, it’s recommended that you use the mysqli_* API instead.
Mysqli_* offers a number of advantages over mysql_*, including the ability to support prepared SQL statements (which protects your app from SQL Injection hacking), enhanced debugging features, an OO interface, and other items.
But both of these API sets have one disadvantage for those of us in the i world: They both work only on a MySQL database. That’s a big disadvantage if you’re a web programmer, because even though MySQL is ubiquitous on the web, there are other databases, and if your app has any portability potential, you want to be able to easily switch from one database to another. And, of course, if you’re writing applications for the i, chances are that you will be wanting to pull at least some of your data from a DB2 database, which is definitely not MySQL.
Fortunately, another option can be used with PHP: PHP Data Objects (PDO).
PDO is not part of PHP per se. It’s a bolt-on, but it has shipped with every version of PHP since 5.1. Bottom line, you don’t have to do anything special to get PDO to work as long as you’re using 5.1 or above. It requires some of the OO features that were added in release 5, so it does not work for PHP releases below 5. Essentially, it consists of two pieces: the core PDO functionality, and a set of PDO data-access drivers that are database specific. When compared with mysql_* and mysqli_*, PDO has several advantages.
The first is that PDO comes in a variety of flavors, supporting about a dozen or so databases, including DB2 and MySQL, thus making it ideal for an i app and doubly so for one that accesses both DB2 and MySQL data. Among the other databases it supports are Oracle, Firebird, Formax, PostgreSQL, and others.
The second advantage PDO has is that it incorporates a data abstraction layer so that no matter which database-specific version of PDO you’re using, the same routines are used to actually access the data. Only the command interface that you’re dealing with is database-specific.
The third advantage is that it’s extremely flexible. It can be used in both procedural and OO environments. It has very robust error-handling capabilities. And it provides all of the functionality you will need for your database activities, including prepared statements, commit, rollback, etc.
There Is Another
But wonderful as it might be, PDO has its own set of drawbacks, so we will look one more tool: IBM’s very own DB2 API set called, appropriately, db2_*. But that will be next month’s surprise.
About the Author: David Shirey