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

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.

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.

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

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.

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

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.

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

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