@chazzyDec 17.2008 — #Why not PDO as an option? :p[/QUOTE]
Probably because mysql's PDO implementation is partially broken. if you check out the site, it makes note that mysql prefers the use of mysqli over mysql for production use, and considers PDO_MYSQL a sort of test release/trial/beta.
the use of mysqli has more to do w/ your database version rather than anything. at a protocol level it is a bit faster, it's also inherently object oriented (though also supporting functional use). using mysql against a 5.0 database results in it being slower due to having to translate from the older protocol.
Edit: Also, one of the key features of PDO is transactions. This is the part that kills me
Beware: Some MySQL table types (storage engines) do not support transactions. When writing transactional database code using a table type that does not support transactions, MySQL will pretend that a transaction was initiated successfully. In addition, any DDL queries issued will implicitly commit any pending transactions.[/quote] IIRC, only InnoDB really supports transactions.
@NogDogDec 17.2008 — #Yes, InnoDB support transactions, MyISAM does not, I'm not sure about the other less-used engines.
MySQLi also supports transactions via the [url=http://www.php.net/manual/en/mysqli.autocommit.php]mysqli_autocommit[/url](), [url=http://www.php.net/manual/en/mysqli.rollback.php]mysqli_rollback[/url](), and [url=http://www.php.net/manual/en/mysqli.commit.php]mysqli_commit[/url]() methods.
I've not done much yet with PDO myself, but know a few people who use it regularly without any problems that I know of. You do have to keep your queries pretty generic, with the payoff being that your application becomes less closely tied to a specific DBMS. The downside, of course, is the inability to use any DBMS-specific features (or at least not easily), so it all depends on what your priorities are.
Mostly I've been using MySQLi lately due to its better support of newer/advanced MySQL functionality, as well as the OOP aspect. I often simply create a class extending MySQLi in order to build in some configuration and error-handling stuff directly with it.
@chazzyDec 17.2008 — #Yes, InnoDB support transactions, MyISAM does not, I'm not sure about the other less-used engines.
MySQLi also supports transactions via the [url=http://www.php.net/manual/en/mysqli.autocommit.php]mysqli_autocommit[/url](), [url=http://www.php.net/manual/en/mysqli.rollback.php]mysqli_rollback[/url](), and [url=http://www.php.net/manual/en/mysqli.commit.php]mysqli_commit[/url]() methods.[/QUOTE]
Even if you are, my point was more that the storage engine ignores those commands rather than actually supporting them (how dare I even imagine?). I've actually been using PDO_OCI for a few months now and am happy with it.
@Stephen_PhilbinDec 17.2008 — #Haven't dabbled in the database side of things for a while now. Last time I spent any time with it was writing a class for transactional querying of my database (can't imagine why someone wouldn't use the InnoDB enginge).
It was quite a while ago, though, because I remember checking out MySQLi and reading that it was aimed more at MySQL 5.1. I had already been waiting quite some time for 5.1 when I read about MySQLi and so ditched the idea of using MySQLi. I would have upgraded to 5.1 and had a tinker with MySQLi, but I'm very busy with something else and I've read about how Sun is now branding MySQL as GA despite it still containing critical bugs. So, naturally, I'm rather reluctant to switch to 5.1. I'm actually thinking of trying out other databases, but I'm too busy to be experimenting with databases right now.
@NogDogDec 17.2008 — #[url=http://www.php.net/pdo]PDO[/url] (PHP Data Objects) is a "database abstraction layer" which provides a uniform interface to the database regardless of which DBMS is being used. In a nutshell, the idea is that if you decide to change from, say, MySQL to Postgre, the only thing you would need to change in your code is the DNS connection string, which ideally would mean you'd only need to change one line of code.
Probably the next step up, providing even more abstraction, is the PEAR MDB2 package, which goes further to provide portability between different DBMS's.