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

Wouldn't it have been better for them to able to maintain their database where ever they were? Of course, but how? Simple - put it online. [...] In this article I'll focus on the essential elements of PHP you'll need to use an existing Access database online. One other item that's standard with a Windows installation is the availability of ODBC drivers. These are essential for the use of Access from PHP.

He includes a sample database structure (with "product", "product_category" and "category" tables) and includes some sample code showing how to connect to the remote database and perform some basic actions - select, update, insert and delete

The phrase may sound like an cheap cliché, I know, but I'm not particularly interested in reinventing the wheel each time I tackle a software problem (unless I need a nicer and faster wheel, of course). In this case, the situation does warrant some additional effort considering we'll be trying to connect a batch of mapping classes to a blog's domain model. Given the magnitude of the endeavor, the idea is to set up from scratch a basic Data Access Layer (DAL) so that domain objects can easily be persisted in a MySQL database, and in turn, retrieved on request through some generic finders.

He includes all the code you'll need to create a (namespaced) database adapter (PDO), the mapping layer to tie the domain models together and using it all in a practical "blog" example with posts, comments and users.

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

Security is a part of our work as developers. We need to ensure our applications against malicious attacks. SQL Injection is one of the most common possible attacks. Basically SQL Injection is one kind of attack that happens when someone injects SQL statements in our application. You can find a lot of info about SQL Injection attack. Basically you need to follow the security golden rule: "Filter input, Escape output".

He advocates the use of the PDO abstraction layer to filter out a lot of the issues. Using its prepared statements, you can easily strip out things that just adding slashes to user input wouldn't prevent. He also includes a reminder about database permissions - allowing only certain users the ability to, for example, delete can help provide one more level of security (in other words, don't use a "super user" in production).

Even when the formal definition of the LSP makes eyes roll back (including mine), at its core it boils down to avoiding brittlely-defined class hierarchies where the descendants expose a behavior radically different from the base abstractions consuming the same contract.

He includes an example with a "deleted scene" from the Matrix depicting an attempted override of the PDO functionality with a subclass that, unfortunately, does not match the original's structure/method definitions. The problem was in the difference between the method signature for the "query" method. It help resolve situations like this he recommends creating a "contract" in the form of an interface your code can implement, forcing it to conform to a certain structure. Using this, he provides a rewrite of the "PdoAdapter" class to match the original signature

Last month, MS announced the preview release of SQL Server ODBC Driver for Linux, a 64-bit binary driver for Red Hat Enterprise Linux 5. This is good news for companies using heterogenous platforms e.g. LAMP stack running a PHP application that connects to both MySQL and MSSQL Server. Meaning, these companies no longer have to use third-party drivers such as FreeTDS that MS doesn't support. Then a few days ago, MS released version 1 of the driver. I immediately downloaded the driver and recompiled PHP with it as a PDO (PHP Data Object) ODBC driver.

His process has five steps to it, including one for making a test script (code included) and another with a few gotchas/performance considerations to keep an eye out for when using the driver.

Sessions are a tool which helps the web programmer overcome the stateless nature of the internet. You can use them to build shopping carts, monitor visits to a website, and even track how a user navigates through your application. PHP's default session handling behavior can provide all you need in most cases, but there may be times when you want to expand the functionality and store session data differently. This article will show you how the default functionality works and then goes on to show you how override it to provide a custom solution.

They introduce how sessions are stored normally (based on the save path) and what the serialized contents of it would look like. They show you how to take this, normally stored on the local file system, and change it to be written to a "session" table in a MySQL database (via PDO). It includes reading, writing, updating and some garbage collection to clean out old values from the table.

I love PHP's PDO (PHP Data Objects) extension; it gives a consistent, object-oriented interface to handling all kinds of relational database backends. One thing that annoys me is that the MySQL driver for PDO defaults to a silent error mode which can make SQL errors tricky to spot!

In her two code snippets she shows a failing PDO request (that fails silently) and a method for catching this issue - checking the result of the "errorCode" method to see if it equals "0" (zero). If there were errors, you can use the "errorInfo" function to get to them. This will return the SQL error code, the driver-specific error code and a driver-specific error message.

The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

The presentation (as posted to Slideshare) starts with some of the basics - what SQL injection is and an example of how it could be used to bypass security. He covers how to use prepared statements in each of the technologies (with code snippets), methods for escaping data and how to create stored procedures that are protected from the same threats.