ZendCon Session Notes - PHP Data Objects
Presented by Wez Furlong (Omni TI)
Problems with PHP Databases APIs
There's no consistency of API between DB extensions. Sometimes, the DB extensions aren't even internally consistent. This also means that there's code duplication in PHP internals, and also leads to high maintenance.
The PDO Solution
Move PHP-specific stuff into one extension, database specifics in their own extensions, and create data access abstraction, rather than database abstraction.
Most people aren't using abstraction layers, or are using home-brew layers because existing generally available abstraction layers are too slow, do too much, or are too complicated.
PDO Features
Native C code, rather than a PHP-based abstraction helps performance. It also takes advantage of improvements in the PHP 5 internals.
PDO has common database features as a base, and database-specific features are also available.
What Can PDO Do?
In summary: prepared statements, bound parameters, transactions, LOBs, SQLSTATE error codes, flexible errorhandling, and database portability.
PDO supports MySQL. PostgreSQL, ODBC, DB2, OCI, SQLite, and Sybase/FreeTDS/MSSQL.
Wez then talked about how to use PDO. I'll spare you pages and pages of PHP code, which I'm sure is given in examples on the PHP website.
PDO maps error codes from the database-specific format to standard ANSI SQLSTATE error codes. In the case of errors, PDO also has three error handling strategies: silent (by defaut), displaying warnings, and throwing exceptions.
PDO implements forward-only cursors by default. (This is similar to mysql_unbuffered_query.) This makes them fast, since you don't have to wait for all the data to come from the network, but it also means that you don't know how many rows there are until you've fetched all the data. It also means that you can't initiate another query until you finish fetching all the data, and it's possible that it might cause other queries to block because the database is still busy servicing your initial query. You can also request buffered queries (like mysql_query) instead.
PDO implements iterators: foreach($dbh->query(...) as $row) {}. Kinda neat, especially since 95% of the time, I wind up doing while($row = mysql_fetch_*()) anyway.
PDO handles LOB support via streams. Database support permitting, you can potentially stream content to or from the database without first having to load it entirely in PHP. For example, you could select an image from the database and fpassthru() it to the browser, or fopen() a file from the filesystem and stream it into the database without having to file_get_contents(). This cuts down on both memory usage and latency.
This talk actually has me excited about PDO now, and I'm going to look into implementing it in my applications where possible.
Problems with PHP Databases APIs
There's no consistency of API between DB extensions. Sometimes, the DB extensions aren't even internally consistent. This also means that there's code duplication in PHP internals, and also leads to high maintenance.
The PDO Solution
Move PHP-specific stuff into one extension, database specifics in their own extensions, and create data access abstraction, rather than database abstraction.
Most people aren't using abstraction layers, or are using home-brew layers because existing generally available abstraction layers are too slow, do too much, or are too complicated.
PDO Features
Native C code, rather than a PHP-based abstraction helps performance. It also takes advantage of improvements in the PHP 5 internals.
PDO has common database features as a base, and database-specific features are also available.
What Can PDO Do?
In summary: prepared statements, bound parameters, transactions, LOBs, SQLSTATE error codes, flexible errorhandling, and database portability.
PDO supports MySQL. PostgreSQL, ODBC, DB2, OCI, SQLite, and Sybase/FreeTDS/MSSQL.
Wez then talked about how to use PDO. I'll spare you pages and pages of PHP code, which I'm sure is given in examples on the PHP website.
PDO maps error codes from the database-specific format to standard ANSI SQLSTATE error codes. In the case of errors, PDO also has three error handling strategies: silent (by defaut), displaying warnings, and throwing exceptions.
PDO implements forward-only cursors by default. (This is similar to mysql_unbuffered_query.) This makes them fast, since you don't have to wait for all the data to come from the network, but it also means that you don't know how many rows there are until you've fetched all the data. It also means that you can't initiate another query until you finish fetching all the data, and it's possible that it might cause other queries to block because the database is still busy servicing your initial query. You can also request buffered queries (like mysql_query) instead.
PDO implements iterators: foreach($dbh->query(...) as $row) {}. Kinda neat, especially since 95% of the time, I wind up doing while($row = mysql_fetch_*()) anyway.
PDO handles LOB support via streams. Database support permitting, you can potentially stream content to or from the database without first having to load it entirely in PHP. For example, you could select an image from the database and fpassthru() it to the browser, or fopen() a file from the filesystem and stream it into the database without having to file_get_contents(). This cuts down on both memory usage and latency.
This talk actually has me excited about PDO now, and I'm going to look into implementing it in my applications where possible.