I think, whenever we see a chart in a magazine, in books or applications our brain say's to us Yeepie!!! Don't read these stupid texts or tables! Just look at the green or yellow line and hope that they are above the other lines or hope that your opinion is the biggest part of the pie¯. This saves us a lot of work and in my opinion we should concentrate on drawing beautiful colorized pie charts, instead of writing long boring articles. But the question is: ¯How do I draw these beautiful colorized pie charts? The simple answer is: you don't have to, because google will draw them for you and you just have to tell them what to draw via the google charts api.

The sample application is a "breakfast rating" tool that logs the results to a MySQL database via PDO calls. The results are then extracted and formated as JSON to be compatible with the Google Charts API data handling. Some sample Javascript is included showing how to call the Charts API with your data and get back a simple line graphing of the data from the database. You can see the application in action here for reference.

When I state "as is", I truly mean the way it's being used in production. So the database call collects real data on which business logic is applied. You can see this is not a healthy situation, especially when you also have services that apply business logic on data and store it back into the database. In "Chris Hartjes wrote this one sentence that says it all: "Unit test suites are meant to be testing code, not the ability of a database server to return results". And he's right, you shouldn't use database connections when your testing business rules and functional logic.

He goes on to show a few code examples that show a pre-mocked state of testing where the Product information is pulled directly from a PDO connection. The more correct version mocks out this object, though, and overrides the "execute" and "fetchAll" methods to return mocked results.

The PDO extension supports twelve drivers, enabling it to connect to a variety of relational databases without the developer having to learn a number of different APIs. It does this by abstracting the database interaction calls behind a common interface, enabling the developer to utilize a consistent interface for different databases. This of course gives it a major advantage over both the MySQL and MySQLi extensions who are limited to only one database.

Included in the post are examples of some of the basics - connecting, executing queries, getting the results - as well as more compelx things like binding parameters and transaction support. There's also a bit about changing the default behavior of the PDO object through config options. He finishes off the article talking some about some of the issues that could come from using an abstraction layer like this and the need to still write good, compatible SQL depending on the database.

I'm not a big fan of ORMs, especially in PHP world when all dies at the end of each request. Plain SQL is easy to understand and very powerful. Anyway in PHP we have Doctrine. Doctrine is a amazing project, probably (with permission of Symfony2) the most advanced PHP project, but I normally prefer to work with SQL instead of Doctrine. [...] Due to my daily work I need to connect to different databases (not only one) in my applications.

He shows the normal setup using the "parameters.yml" file to define the multiple database connections but notes that this isn't the most ideal solution. Instead, he walks you through the steps to create the "databases.yml" configuration file and a simple "Db" class that acts as an interface to pull the PDO objects from the container. You can then just call the "get" method on the container to extract the fully configured PDO object, ready for use.

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 the last tutorial in this beginners series we discussed using PDO to connect to a MySQL database. Following on from that tutorial we are going to improve the Guitar class we made by adding some basic CRUD methods so that our class can interact with our database using PDO.

He brings back the same class structure and shows how to take a "Guitar" object, create a connection via a "conn()" method and use the getters/setters to assign values for saving, selecting, deleting and updating the database's records.

We've covered PHP's PDO API a couple of times here on Nettuts+, but, generally, those articles focused more on the theory, and less on the application. This article will fix that! To put it plainly, if you're still using PHP's old mysql API to connect to your databases, read on!

They compare the three main methods for connecting to a MySQL database - mysql, mysqli and PDO - and how a typical mysql/mysqli codebase can be refactored to use PDO. They show examples of connections, error handling, fetching data, using prepared statements and snippets of code for CRUD (Create, Read, Update, Delete) handling.

Be sure and check out the comments - there's some great tips there too!

For our database connections we PDO at work and we've extended the class with PHP to offer some other convenience functionality and wrappers. One of the things I wanted to do recently is allow the constructor of the PDO class to fail-over to our backup database connection pool in the event the primary was not available.

He wanted his code to catch an exception if the object was created with a failed server host and to connect to the backup instead. PDO doesn't cooperate with this method and just destroys the object when there's a failure. His work around is in this patch to the PDO support in PHP to provide a new constant, PDO:: ATTR_KEEP_CLASS_CONN_FAILURE, that tells the script wether or not to destroy the PDO object when there's a problem.

I can code fairly well in PHP these days, but my security isn't so hot. Is there a tutorial or plugin you guys can recommend as to how I should be protecting my php pages/inputs? I want to avoid common attacks like XSS, inputs with NULL or DROP TABLE etc?

Responses on the post include recommendations related to:

• Using the Chorizo scanner to find common issues in your code
• Using PDO for database connections (with bound parameters)
• Not trusting "$_SERVER"
• Data sanitization

There's also links to a few other resources with more details.

If we don't use an ORM within our projects we need to write SQL statements by hand. I don't mind to write SQL. It's simple and descriptive but sometimes we like to use helpers to avoid write the same code again and again. Today we are going to create a simple library to help use to write simple SQL queries.

It's a lightweight library that'd be good for basic uses, but when you start getting into something a bit more complex, something like Doctrine2 or Propel might be a better solution (or whatever your framework of choice has built in).