On the PHPDelusions.com site there's a post that compares the functionality of mysqli to PDO and looks at the differences in their overall usability.

By no means I am going to say that mysqli is worse than PDO. Mysqli is an excellent extension, with many specific features. But it's just not intended to be used directly. To make it usable, one have to always wrap it into a helper library, to reduce the enormous amount of code that otherwise have to be written by hand.

[...] But for the average PHP/MySQL user, standard APIs are the only known methods for database interaction. Thus they tend to use both extensions right in the application code, without any intermediate wrapper around. For such a use PDO is an indisputable winner, and I'll show you why.

The post then breaks it down into sections comparing the functionality between the two database access methods:

• Named placeholders
• General inconvenience in binding
• Getting single column value
• Getting multiple rows
• Binding unknown number of parameters
• Compatibility

Of course, all the inconveniences above could be overcame by a good wrapper. This is why if you choose mysqli, you definitely have to use one.

In his latest post Dougal Campbell shares his findings from a bug he was having with a plugin in WordPress. It revolved around the use of mysql or mysqli and errors being thrown to his logs.

The plugin had previously worked fine (it generates a sidebar widget), and I wasn’t actively working on my site, so I wasn’t really sure when it had quit working. In the course of debugging the problem, I discovered that the plugin was throwing warnings in my PHP error log regarding the mysql_real_escape_string() function. As a quick fix, I simply replaced all of those calls with WordPress’ esc_sql() function. Voila, problem fixed.

He was interested in why this worked, though, and went digging in the code. As it turns out, the WordPress code tries to determine which mysql extension you have support for. As it turns out, his installation fit the "mysqli profile" so the "mysql_real_escape_string" wasn't available. To the WordPress users out there, he suggests esc_sql or $wpdb->prepare() instead.

On the HHVM blog today a new post talks about some of the work they've been doing to introduce one of the common PHP extensions, MySQLi, into the HHVM system. The post walks you through some of the process the author followed to work up the implementation.

To prepare for what was to be my big project, I rewrote the ini parser to better match Zend. [...] After warming up with the parser, I was ready to start my big project: implement MySQLi. This has been a long requested feature for HHVM. And, this extension is required to help meet our compatibility goals.

He walks you through some of the preparation steps for the work integrating the extension and the tools used for these initial steps. He briefly steps through the actual implementation and the testing of the feature (and some changes made to allow the tests to run faster). He mentions a few roadblocks hit along the way, the current status of the effort (182 passing tests, 114 failing) and some of the missing pieces yet to be worked.

On PHPMaster.com today there's a new post, the first in a series, about avoiding the original MySQL extension in favor of what mysqli has to offer. The cover some of the basics of the extension and include code showing its use.

Experienced developers eschew the original MySQL extension because of its abandoned status in PHP. Nascent web developers, however, may be completely oblivious to its dormant past and dying future. [...] It is therefore the intention of this two-part article to raise awareness among developers who still use the MySQL extension, inform them of its problems, and to help them switch over to an alternative extension.

They start with a brief look at the "what's wrong" with the MySQL extension (including its upcoming deprecation). The article then gets into the basics of MySQLi and how to do things like make a connection and run a few queries. There's also a bit about prepared statements and the built-in ability to do "multi-queries" (complete with rollbacks).

Related to a recent discussion on the php.internals mailing list, Chris Jones has posted about moving away from the MySQL extension in favor of the MySQLi functionality and the effort bubbling up to make the old functionality deprecated.

An important discussion on the PHP "internals" development mailing list is taking place. It's one that you should take some note of. It concerns the next step in transitioning PHP applications away from the very old mysql extension and towards adopting the much better mysqli extension or PDO_MYSQL driver for PDO. This would allow the mysql extension to, at some as-yet undetermined time in the future, be removed.

He links to a RFC that's been posted to help promote and push this idea forward with mentions of the "carrot" and "stick" methods for pushing users towards mysqli.

As always, there is a lot of guesswork going on as to what MySQL APIs are in current use by PHP applications, how those applications are deployed, and what their upgrade cycle is. [...] I want to repeat that no time frame for the eventual removal of the mysql extension is set. I expect it to be some years away.

In this recent post to his blog Thilanka Kaushalya shows how to use transactions in MySQL databases (using mysqli

Web applications are more popular today than ever with the increasing number of internet users. Most of the standard alone applications converted as web based applications or at least they try to provide a web interface for users. PHP and Mysql are two leading technologies which allow uses on rapid development of web based systems. "Transaction" is a powerful concept which comes with Mysql 4.0 and above versions. Lets explore that.

He introduces the concept of transactions first, providing an example of a bank transfer between two individuals. He uses this to create a simple code sample that turns off the autocommit for the connection (using mysqli_autocommit set to false) and running the SQL in order before the commit. He also includes an example of using the rollback function to return the data back to its original state if there's an error.

On the NetTuts.com site today there's a quick tutorial comparing two of the main database access methods available to PHP developers - PDO and MySQLi - based on performance and features they each have.

When accessing a database in PHP, we have two choices: MySQLi and PDO. So what should you know before choosing one? The differences, database support, stability, and performance concerns will be outlined in this article.

The article starts with a summary of what each of the tools offers as far as features, things like the API to work with the interface, difficulty of making connections, use of prepared statements and performance. This is followed by a few code examples showing the same actions on each side:

• Making a new connection
• Databases supported (PDO has drivers)
• Named parameters
• Object mapping
• Security
• Performance

Ultimately, PDO wins this battle with ease. With support for twelve different database drivers (eighteen different databases!) and named parameters, we can ignore the small performance loss, and get used to its API. From a security standpoint, both of them are safe as long as the developer uses them the way they are supposed to be used (read: prepared statements).

Ulf Wendel has a new post to his blog pointing out the new mysqli quickstart that's been added to the PHP manual.

New in the PHP manual: a mysqli quickstart. You are new to PHP but you know how to code, you know SQL, you know relational databases and MySQL? Then, I hope, this is for you. All you need is a quick overview on the concepts? The rest is in the reference section! Here you go.

It includes sections on:

• making connections
• executing statements
• stored procedures
• multiple statements

Ulf Wendel has a new post today with details on using stored procedures with mysqli - not overly difficult if you know how to handle the IN, OUT and INOUT parameters. He includes a few code examples showing how to use them.

Out of curiosity I asked another friend, a team lead, how things where going with their PHP MySQL project, for which they had planned to have most of their business logic in stored procedures. I got an email in reply stating something along the lines: "Our developers found that mysqli does not support stored procedures correctly. We use PDO.". Well, the existing documentation from PHP 5.0 times is not stellar, I confess. But still, that’s a bit too much... it ain’t that difficult. And, it works.

He describes the three parameters (IN, OUT and INOUT) and gives some examples of setting/getting them from your SQL statements. They're all still set up using the query method on your connection as well as handling the result sets that come back and working with prepared statements.

Volker Dusch has a new post to his blog looking at the use of references in PHP (or lack there of) and what we, as end users of the language, can do about it. His example looks at mysqli prepared statements.

Even so not every PHP Developers knows WHY we don’t use references pretty much every core function and every somewhat modern framework avoids them so people adapted this best practice. The leftovers in the PHP core, like sort() or str_replace(), are exceptions to the rule. So if the common consensus is, or at least 'should be', that we should not use references then maybe we should start looking for places where they hurt and how we could fix them?

He talks about prepared statements and one thing he sees that makes it a "hard sell" to developers needing a good way to query their databases. He points out the difference in code required between the normal MySQL calls and mysqli (hint: it's more) and shows how to use an abstraction layer to make things a bit easier. He points out the downfalls of using this approach, mainly the performance hit you get (from using his fetchAll method).