In this new post to his blog, Gonzalo Ayuso compares two technologies that can make working with databases in your applications simpler - PDO and the Doctrine2 DBAL layer.

In fact DBAL isn't a pure database abstraction layer. It's built over PDO. It's a set of PHP classes we can use that gives us features not available with 'pure' PDO. If we use Doctrine2 we're using DBAL behind the scene, but we don't need to use Doctrine2 to use DBAL. We can use DBAL as a database abstraction layer without any ORM. Obiously this extra PHP layer over our PDO extension needs to pay a fee. I will have a look to this fee in this post.

He includes a few simple benchmarking scripts that compare similar operations done by either, including memory usage and execution time. PDO comes out on top, obviously, because it's an extension versus a set of PHP libraries that need to be included in the application. He does include examples of a few things he likes that DBAL does that PDO doesn't by default - a transactional mode, type conversion, a simpler binding interface and the ability to nest transactions.

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).

Sameer Borate has posted about an alternative templating system that's currently being used in multiple languages - Haml (HTML Abstraction Markup Language). As Sameer points out, there's also a PHP port of it.

It has been a while since I've used a template engine during development, the last one I used was Smarty. Now there are a plethora of template systems, but most are a rehash of Smarty. Readers may beg to differ, but Smarty gets the work done, which is all that matters. The one that I found really interesting is Haml.

He includes some markup examples of how it's structured - the main structure of the site, tables, divs, etc - and what it comes out like on the other side of the parser. The phphaml and phamlp libraries let you run the template through with variable values set and display it. There are some downsides he mentions, though, like the rules on indentation and that the markup has to be all in one file (or combined before sending to be rendered).

On the php|architect blog today Bill Karwin looks at a new library - Crystal - a database library to help make it simpler to work with SQL (and make it more human-readable).

Martin [Rusev]'s project is called Crystal. It's an object-oriented wrapper for the venerable mysql and pg extensions, with the goals of making SQL more human-readable, and providing a library that is lightweight and easy to learn.

There's code examples on the site of how to use the library. Bill also mentions some of the things the project does well and a few things it doesn't - like leaving out some of the advanced SQL functionality in favor of simplicity. He also mentions concerns about SQL injection handling, code not shared between database handlers and the unfinished nature of some features.

Jani Hartikainen has a few suggestions on how to handle exceptions in your application - more specifically how to handle them in your classes and still keep proper abstraction.

So you already know how to handle your errors properly. Even if you're already using exceptions, there are some nuances to the use of exceptions that are important to know and understand in order to write code that is easier to reuse and more decoupled. Let's talk about exceptions and how they relate to your classes and abstraction.

He looks at classes/abstraction, how they relate to normal and custom exceptions and how to design your code better to wrap exceptions in custom handlers to make maintainability even easier. He also suggests catching everything in more general exceptions as well, giving you an overall way to handle abstracted exceptions.

Brandon Savage has posted his latest part of his "Peer Review" series. He takesa step back and looks at abstraction again, this time incorporating some of the suggestions other members of the PHP community gave based on the previous version.

This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we're focusing on the implementation of the database, it's important to note that we will also need to address some of the logic (which will be the next part of the series).

He looks at assumptions (how they can be bad), the use of an ORM layer to help negate some of the problems surrounding them and adding in some exceptions to properly handle issues that might come up.

Brandon Savage has posted his latest article in his series looking at refactoring a piece of code (starting here) focusing in on the abstraction already in the code and how it can be made better.

This article will focus on the constructor method. There are a couple of problems, namely that the constructor itself does a lot of actual work. Also, we have the cURL setup done in the constructor. This object is a Twitter object, not a cURL object; this means that we should decouple the cURL functionality and abstract it into a separate object of its own.

He recommends splitting out the current method the class uses to create the cURL connection (setting it up in the constructor) and making a separate HTTP class that can be pulled in as an object and used as a sort of API. The full code of the new class is also included.

In response to this older post Ralph Schindler has posted some of his own thoughts on database abstraction layers - they must live!

Interestingly, I can put the vocal proponents of each side of the argument in one of two boxes: a programmer guy box, or a database guy box. For some unknown reason though, they never seem to see eye to eye. [...] Generally speaking of database driven projects, I feel like planning to use a specific vendor up front, knowing its pro's and con's, and tailoring an application to the chosen database's strengths can only help in the long run. Also, I feel that building a database model first before any code, offers many performance and scalability advantages than does code first development.

He notes that, while he agrees on the problems with the "switching databases at any time" problems the other author brings up, he points out that the abstraction layers do have their place. He includes an example of an abstraction layer with the Zend_Db object of the Zend Framework. His sample code shows how it can be used to simplify your interaction with your database.

Jeremy Zawodny has shared his opinion on database abstraction layers in PHP applications - they need to die.

Beware of men preaching of false hope. Take, for example, the way some folks feel like they need a database abstraction layer in their applications. [...] So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

He goes on to say that, despite the claims that people make about portability ("it's never that easy") and ease of use, the only real answer is to strip out this layer and use good programming practices to take the database access code out into a separate library that can be replaced quickly and easily.

On PHPBuilder.com today there's a new article looking at how to get PHP and MySQL working together on your server and make the connection between the two in a simple script.

Until you properly understand what happens in the background--on the server--while your code is being processed, you will not have the tools to eliminate slow server responses. I am not, however, talking about the actual machine process that happens on the server. I am simply talking about what happens when you type echo, or print, or foreach. What are you telling PHP to do?

They start with a basic look at working with PHP then move on to creating a simple database interface class. With this in had, they show how to create a simple abstracted query and handle the results.