PHP 5, Oracle, and the Future

PHP 5 (PHP: Hypertext Preprocessor Version 5) was officially released on July 13, 2004. Not surprisingly, the release was widely covered by the media due to the leadership role PHP plays in the Web application market. It is true that technologies such as .NET and J2EE have had more exposure and hype than PHP, but ease-of-use, performance, tight integration with the Apache Web server, and a large collection of application building blocks have made PHP one of the leading Web application development languages.

You might ask yourself, since PHP 4 featuring the Zend Engine was so successful, why do we even need PHP 5 and the Zend Engine II? The truth is that there are certain areas in which PHP 4 does not excel. Most of these areas are more important for large projects and companies, where project management is more structured and interoperability between systems is a must. PHP 5 addresses these issues, allowing PHP not only to be more attractive for such projects but also to remain a leading technology for Web application development.


General Released in July 2004, PHP 5 has only been around for a short time. Despite that, there are already quite a few interesting things happening in PHP development. There has been a lot of work on improving the performance of the scripting engine and, most importantly for the Oracle readers, there are many new database-related initiatives. Use of Oracle is strong in the PHP community, and a large amount of Zend customers are Oracle users. Their use of Oracle varies as it does with other databases but is usually a very conscious choice, which has to do with Oracle's proven track record, advanced features, and often an already existing investment in Oracle infrastructure.

Scripting Engine Performance When developing PHP 5, Zend and the community focused more on functionality than on performance. Therefore, except for a few exceptions, performance of the scripting engine was not improved between PHP 4 and 5.

In most PHP applications, the raw execution performance of PHP is not the main bottleneck. The most common bottlenecks are related to I/O and are usually database-related. That said, we still believe that improving the performance of the scripting engine itself will definitely benefit the PHP user. For this reason, we decided to invest significant resources to improve performance for PHP 5.1.x.

Since the release of PHP 5, we have invested a lot of resources in tuning the scripting engine. Many ideas were taken from a performance patch that Thies Arntzen and Sterling Hughes published about a year ago. Other ideas came from inside Zend and the PHP developer's community. The end result is an engine that is commonly more than twice as fast as PHP 4.0 and PHP 5.0 for synthetic benchmarks (benchmarks that don't include I/O and real-world code).

The improvement is quite impressive, and when PHP 5.1.0 is released all of the PHP users will enjoy it without having to make any changes to their source code. I believe that PHP 5.1.0 will be released early in the first quarter of 2005, but one can never tell with an open source project.
SQL Relay. SQL Relay (is a very interesting third-party project. It is a project that implements a proxy broker for SQL connections (including Oracle), allowing for connection pooling of database connections using PHP.

The project provides its own version of a PHP database extension (you will be required to change your PHP database code). This extension talks to the SQL Relay broker that relays queries and result sets to and from the database.

Some of SQL Relay's advantages:

• Using connection pooling, you can limit the amount of open connections to the database.
• In case PHP persistent connections can't be used in your environment, this solution solves the problem of long connect times when initiating an Oracle database connection.
• The project supports other programming languages too. If you have a hybrid environment, you can take advantage of the same SQL Relay daemons that are being used from PHP. In addition to PHP, language support includes C, Java, Perl, and quite a few more.
• Getting up and running with SQL Relay, although not trivial, is quite simple. I'd also like to note that the SQL Relay author was very responsive to my questions.

Some of SQL Relay's disadvantages:

• You have to use a different API than the PHP Oracle extension.
• Result sets are copied twice: first to the SQL Relay broker and then to PHP.
• You don't have as rich an API as you do when using PHP's native oci8 extension.

I think that if your project does require Oracle database connection pooling, it is a good idea for you to check out SQL Relay. It might not be perfect, but it might still take a while until a better solution comes along, and this one does seem to work.

PDO The PHP community has been working on a new database abstraction layer in addition to the existing oci8 PHP extension that has a native interface to the Oracle Database. As Oracle Technology Network already has an in-depth article covering PHP Data Objects (PDO), by Wez Furlong, suffice to say that PDO is something to watch. PHP has been waiting for quite some time for good native database abstraction. I believe that PDO may very well be the solution we have all been waiting for. The designers of PDO are some of the lead developers of the PHP community, and I like their approach with PDO. The following is a list of their design goals, as written in the PDO README file:

1. Be lightweight.
2. Provide a common API for common database operations.
3. Result in high performance.
4. Keep the majority of PHP-specific code in the PDO core (such as persistent resource management); drivers should only have to worry about getting the data and not about PHP internals.

On one hand it gives a common API for working with databases. But it also allows each driver to add its own additional functionality, so that PDO not only supports the least common denominator of the database APIs but will actually give you the opportunity to use all the features your database has to offer. And we all know Oracle has lots of them.

Propel Propel is an object persistence and query framework. It implements object/relational mapping (ORM) and is based on the Apache Torque project, which does the same for Java. Unlike PDO, Propel is a very high-level database abstraction layer, redefining how you query, create, and manipulate persistent objects. Propel, as expected from an OO/RDBMS mapping system, also deals with database schema creation.

There are many advantages to a system like this. For starters, developers can concentrate most of their time on writing business logic and have to deal less with the intricacies of the database—whether it is schema management or writing fancy SQL statements. Database manipulation is very natural, as developers just deal with regular objects and the persistence layer deals with the low-level details of updating the right fields and rows in the database.

The disadvantage is that you do lose some control. The automatic mapping of the OO model to the relational database is not always straightforward. Not only does it make it hard to write fancy, powerful, hand-crafted queries, but you're also not supposed to do so—you break the abstraction, and a tiny update of the mapping might break the application. Therefore, using such a system means you have to play by the rules of the tool. In most cases, this price is acceptable, as increased productivity helps shorten development times and improves code quality. However, there are certain instances where you might absolutely require this control.

Propel is a very interesting project and can come in handy. In addition, it is built on top of a database abstraction layer called Creole. Unlike PDO, this abstraction layer tries to mimic JDBC as much as possible and might be easier to use if you are converting existing Java code to PHP. That said, if PDO becomes mainstream and is distributed as part of standard PHP, it might be best to stick with that.

Java Integration Over a year ago, Zend and Sun Microsystems started Java Specification Request (JSR) 223 to define a standard on how to bridge between PHP and Java. Today the JSR's expert group comprises many software vendors, including Oracle. Although the JSR talks about all scripting languages, the initial interest was in PHP and mainly the possibility of calling Java code from PHP. You can guess that one of the primary motives for such connectivity would be to connect front-end PHP servers to back-end J2EE application servers and, more specifically, the ability to call Enterprise Java Beans (EJBs) directly from PHP code.

PHP 5 has definitely been a great step forward for PHP and the PHP community. At the O'Reilly Open Source conference, a reporter asked some of us PHP community leaders if PHP 5 was everything we had hoped for. The answer was unanimous; PHP 5 has become much more than we initially had planned and expected.

More specifically, I think Oracle users have a lot to look forward to. With Oracle's published Statement of Direction regarding PHP inclusion in future Oracle Application Server releases, it is clear that the company has recognized the importance of PHP technology. I believe that following this recognition will come a variety of solutions that will improve Oracle/PHP productivity and flexibility, both very much required in today's ever-changing market. The initial bundling of PHP in the upcoming version of Oracle 10g and the PHP extension for Oracle JDeveloper are significant first steps for widespread PHP support by Oracle.