Larry Garfield wrote:
On Tuesday 07 August 2007, Lester Caine wrote:
Lester Caine wrote:
Christopher Jones wrote:
Lester Caine wrote:
I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they become incompatible, so in addition to the PDO
driver you need to also run the native driver simply to provide the
areas NOT covered by PDO. We need a generic framework that addresses
the real problems not one that creates an artificial lowest common
denominator strangle hold :( PDO could evolve into that, but not with
it's current restrictions.
Can you list the current restrictions as you see them?
Actually the very first one has been addressed and has nothing to do
with PDO. Up until recently is was essential to provide backwards
compatibility with PHP4 and all of the projects I currently work with
WOULD still install on PHP4. Although *I* never used it in production,
the continued support meant that there was a large base that insisted on
retaining it. So ADOdb's continued underlying support for PHP4 is useful
and until there are a higher percentage of PHP5 users than PHP4 - PDO
takes second place as it is not available on a large number of hosts?
As you noted, this one is no longer an issue[1][2].
[1] http://gophp5.org/
[2] http://www.php.net/index.php#2007-07-13-1
The next problem builds on the above one. From the PDO manual "PDO does
not provide a database abstraction; it doesn't rewrite SQL or emulate
missing features. You should use a full-blown abstraction layer if you
need that facility." ADOdb will run PDO drivers quite happily, but on
current information the performance of the PDO drivers is slower than
using the same native driver. So given a choice the native one is
preferable and currently essential for PHP4 support.
I've seen some of the numbers posted, at least as far as MySQL. As Ilia has
noted before, MySQL's native prepared statement support sucks all on its own.
It's faster to use PDO's internal implementation.
That said, you need to make a direct comparison. PDO, especially with
prepared statements, does a lot more processing than a direct implementation.
That takes a lot more cycles than just passing mysql_query() a string.
However, just passing mysql_query() a string is not secure. You need to
implement your own escaping mechanism on top of it (because trusting yourself
to always call mysql_real_escape_string() in every instance is a recipe for
disaster). That takes even more cycles, because it's happening in PHP rather
than in C.
As a case in point, I recently tried to implement a PDO layer for Drupal as an
alternative to the mysql_* implementation. Drupal currently implements its
own prepared statements in user-space, using a printf()-like syntax and
preg_replace_callback(). When I replaced that with PDO's own prepared
statements, I found performance was about a wash[3]. On the other hand we do
get type-safe prepared statements and simpler code, so we're planning to move
to PDO in Drupal 7 at this point.
[3] http://drupal.org/node/134580
NEITHER of the above are restricted to Firebird and apply equally to all
databases, but they are the main reason to date that no one has had the
inclination to fix the pdo_firebird driver as it's deployment potential
is currently limited.
My knowledge and experience with Firebird is nil, so I cannot say anything
useful for that.
The internals of PDO restrict things to using SQL access to the
database. While it will probably be said that the database should ONLY
provide SQL access to everything, Firebird has a services interface
which is used for such things as backup, user management, and the event
handler. How should all those be handled if they are moved to the PDO
driver?
Are you talking about Firebird-specific features, or all non-SQL-standard
queries? As far as I know PDO allows arbitrary strings as queries so
SQL-esque database-specific stuff should still work. Wez, is that not the
case?
I make no claim of being a PDO expert either, and my database experience is
98% MySQL, but the above is my experience and reading so far with it. PDO's
main selling points are 1) A fully OO API and 2) A common API for all
databases. By nature, it does result in "lowest common denominator" issues
as well, including potentially performance. If you're aiming for
cross-database compatibility, I'd recommend it over rolling your own. If you
can guarantee that you'll only need <insert some database here>, then the
specific driver may be a better option in some cases. YMMV and so forth.
No, the idea is that there is a common set of methods and a common
infrastructure to support those. However every driver is free to
implement driver specific things and prefix those methods with the
driver name. So in theory all the RDBMS specific goodies in all of the
native drivers can also go into PDO.
regards
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
