Not really, ADODB can use PDO in order to access the databases. PDO is more abstraction of various database APIs, so that you don’t have to change the functions everywhere. It doesn’t abstract the SQL and rewrite it for you like some other Database and SQL abstraction libraries out there.

The query() function uses prepare() in its implementation. You want to turn on Emulate_Prepares for mysql when using it. That might change when the PDO_MYSQLND driver comes out.

I use PDO, because it has less overhead and it does what I need it too. ADODB is implemented in PHP (mostly, there is a PHP extension to speed it up) and PDO is implemented in C. For most of my projects I haven’t needed the power of ADODB and I’m comfortable with PDO after using it for a number of years.

Really, most of my queries are prepared statements, even if I’m making one query at a time, I usually save the prepared object as a static property of the class I’m working in to be used later. I haven’t done any benchmarks to know if it actually is any faster.

I think I saw you somewhere. Anway. Is ADODB out of picture in the case?

I used to use PHP ADODB library and switch database between MySQL and MSSQL. I think PDO may fit my need to convert MySQL into Oracle later on PHP5.2.6+.

I have heard people saying that prepare() function may not use the true MysQL Cache feature on MYSQL server. People recommend to use query() for statement that need to be cached.

Ex.

select SQL_CACHE firstname, lastname from table …

I have never use prepare() with stored procedure to pass in and pass out the record sets. I heard that PDO did not do good job on passing multiple records sets from MSSQL.

Can you really recommend to use PDO for the following reasons, or should I go back to ADODB? I think MYSQLi won’t get me anywhere.

1. Support different databases
2. Performance with cache (a lot of huge tables need to be cached)
3. Support stored procedures with parameters in and out.

Thank you so much! I am glad that I found your blog.

It actually is pretty easy once you get used to the API. Speed can be fine, but more robust? Maybe not. Depends on your needs.

Speed?
Ease of Use? (doesn’t sound like it!)
More Robust?

$a[0] = 'ss';
$a[1] = 'test1';
$a[2] = 'test2';
call_user_func_array(array($stmt, 'bind_params'), $array);

Let’s say that you’re making a mapper class. And in the mapper class, you’re trying to create an “insert($objects)” method that can go get the relevant fields from the object, and insert them.

The way I tried to do it was to count up the fields, use that to make a string of “?,?,?” placeholders, and then pass the array of values into execute(). That works in PDO, the way it does in Perl DBI.

But not with mysqli. As far as I can tell, with mysqli, you prepare the statement, and then you have to bind them explicitly like so:

$stmt->bind_params(“sss”, $foo, $bar, $baz);

Whatever, seems like BS to me. But more importantly, if I’m passing in an array with an arbitrary number of insert values:

1. now I have to do some kind of meta-info about each object attribute? so i can create that string? Bullocks.
2. as far as i know, correct me if I’m wrong, I can’t just do $stmt->bind_params(“sss”, @attrs), they have to be broken out into individual variables. Again, bad bad bad. If this was Perl, it wouldn’t care if I passed in a list of vars or an array. But in PHP, it’s much easier to put things into an param array than to bust individual params out of one. PITA.

So, I’m going back to PDO. If I don’t go back to Perl first.

mysqli works only on MySQL.
PDO can work with many databases.

So, if work with a large project, PDO could be the winner.
I have been using PDO, and i’m very happy. Zend Framework has implemented it.

KISS:

try {
$statement = $mysql->prepare("SELECT COUNT(*) FROM gh_users
WHERE username=:username AND pass=PASSWORD(:password)");

}
} catch(PDOException $e) {
var_dump($e);
}


A common newbie mistake with PDO is wondering why it doesn’t report errors. You need to tell PDO that you want either warnings or exceptions, otherwise it will assume that you’re being a good coder and checking return values and calling errorCode() and errorInfo() in the right places.