In a new post to his site Bob Majdak looks at using SQL in PHP and some of the challenges he's come across (some of them with his own tools). He talks about things line inline SQL, loading SQL by unique key or creating a "build object".

There is no right or wrong way, but no matter what there is no *pretty* way to do SQL inside of a PHP application. I have been having a personal debate with myself all week about how to make SQL statements nicer in an application without going to a huge DBAL package like Doctrine.

He looks at each idea and provides some of the pros and cons about each of them, noting that he hasn't quite decided on which is the best method. Some sample code is included to help clarify the points, showing the "find by unique key" version and how a more complex query might be created with the "builder object."

Maarten Balliauw has a new post to his site showing how you can work with a Azure SQL database directly from the UI of the popular PHP IDE, phpStorm.

PhpStorm provides us the possibility to connect to Windows Azure SQL Database right from within the IDE. In this post, we'll explore several options that are available for working with Windows Azure SQL Database: Setting up a database connection, creating a table, inserting and updating data, using the database console, generating a database diagram and database refactoring.

He includes the instructions and several screenshots showing each step of the above mentioned steps. The database diagram gives you a good overall view of your database structure and allows you to show a visualization of how the tables relate to each other. Note that, though this particular example shows it connecting to an Azure SQL database, the same setup can be used with lots of popular RDBMS out there.

Gonzalo Ayuso has followed up his previous post about creating a simple SQL wrapper with PDO in PHP with this new post, a "part two" looking at improving it a bit with a new class to represent the tables.

In one of our last post we built a simple SQL wrapper with PHP. Now we are going to improve it a little bit. We area going to use a class Table instead of the table name. Why? Simple. We want to create triggers. OK we can create triggers directly in the database but sometimes our triggers need to perform operations outside the database, such as call a REST webservice, filesystem's logs or things like that.

He includes the updated code with the new "Table" class with methods that let you set up pre- and post-action hooks on each of the types (insert, delete, update) along with the rest of the library, there ready for the copy & pasting.

The Agile Toolkit blog has a new post today that looks at speed in PHP frameworks the their relative speed (no, there's no benchmarks here).

This question is often asked, but is never answered properly. So how to measure framework speed? Let me also explain why "scalability" is more important than general "performance". [...] This along with a general overheads of the framework greatly contributes to the "slowness" of your project. So how can framework contribute to performance of your project?

They touch a few different ways that frameworks can help execute things a bit faster like:

• Make Fewer SQL Queries
• Selective render
• Parallelization
• Overheads
• Caching

On the Nerdery blog today there's a new post about the recent Minnesota PHP User Group's latest meeting where the topics were "When SQL Meets Developers" and "Message Queues & Distributed Job Processing".

In their May meeting, the Minnesota PHP User Group heard two talks on "When SQL Meets Documents" [above] and "Message Queues & Distributed Job Processing" [below]. MNPHP meets once a month at The Nerdery's office in Bloomington.

Both of the presentations were recorded - you can find the videos over on Vimeo: SQL Meets Developers and Message Queues.

In this new post to his blog Gonzalo Ayuso has shared a simple SQL wrapper that he uses to work with his databases. It takes in an injection of the database connection component (a href="http://php.net/pdo">PDO) and provides functionality for inserts, updates, etc. with transaction support.

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

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren't they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

In a recent post to his blog, Gonzalo Ayuso shares a few tips on preventing SQL injection attacks on your applications.

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

In a recent post to his blog Brian Swan takes a look at working with sessions in PHP and, specifically, how to save them to Azure along with all of their data.

In my last post, I looked at the session handling functionality that is built into the Windows Azure SDK for PHP, which uses Azure Tables or Azure Blobs for storing session data. As I wrote that post, I wondered how easy it would be to use SQL Azure to store session data, especially since using a database to store session data is a common and familiar practice when building distributed PHP applications. As I found out, using SQL Azure to store session data was relatively easy (as I'll show in this post), but I did run into a couple of small hurdles that might be worth taking note of.

He uses PHP's own session_set_save_handler to point to his custom Azure handling class with the needed methods (like write, close and destroy). He breaks it out into three simple steps, some with a bit of code attached:

• Create the database, table, and stored procedure
• Add the SqlAzureSessionHandler class to your project
• Instantiate SqlAzureSessionHandler before calling session functions as you normally would

The code for the Azure handling class can be downloaded here.

From the Developer Drive blog there's a recent post with some suggestions on how you can help to prevent SQL injections in your PHP application and make it that much harder for would-be attackers to do what they shouldn't.

Why do SQL injections happen so often? The shortest answer is that SQL injections are so popular because of poor programming. Hackers know about the potential of a successful SQL injection attack and they search for vulnerabilities. Unfortunately, very often they don't have to search hard - vulnerabilities pop right in their face. [...] The good news is that fortunately, SQL injections are also relatively easy to prevent.

They list nine easy things you can do to help prevent the attacks:

• Patch your SQL server regularly
• Limit the use of dynamic queries
• Escape user input
• Store database credentials in a separate file
• Use the principle of least privilege
• Turn magic quotes off
• Disable shells
• Disable any other DB functionality you don't need
• Test your code