Application level SQL performance is much different than the performance of the SQL query itself but rather how it has been designed to work in the application. Many of the items I will be addressing in this area is designing your application to make less queries thus improving scalability and likely performance. However, performance does not always equal scalability as the same with scalability does not always equal performance.

He looks at a few different topics like lazy connections, iterating queries, need-based selects, normalization and a few simple things that you can apply to every SQL your application uses to optimize it as much as possible.

Trent Richardson created a very small and simple JsonSQL library for JavaScript which allows you to run an extremely limited subset of SQL against a Json array/object. I quickly ported it over to PHP 5 and it works like a charm, although the syntax for the WHERE clause isn't exactly the same but the rest ported across properly.

He's included some sample source code of it in action - selecting information out of an array of user information, once changing their order and the other grabbing a username. Complete source for the library is included too.

Recently at work, I was tasked with finding a method to retrieve data from a third-party SQL Server 2000-based system into our own MySQL-based application. It's worth noting that both system are behind their own firewalls and I was trying to bear security in mind as I did this.

Some highlights of his work included using GoToAssist to get to the system, using EMS SQL Manager to work with the SQL server itself and some of the PHP code he "threw at it" to grab the info he needed from the database (with the PDO drivers).

Eventually the simple distance formula that I have blogged about turned out to be too inaccurate, even for locations within city bounds. I needed to use a formula to calculate great-circle distance which takes into account that the Earth is a sphere.

He includes the SQL to pull the data in the right format and the PHP code (using Propel) to reproduce it without having to write it by hand (complete with the bind variables to help with security and consistency).

For example, check out the documentation for the NTILE Function. Yeah, sounds kind of boring. What good could it be in the wonderful world of web development? After all, who manages employee or sales tables anymore... Answer: generating tag clouds.

Her SQL statement categorizes the tags for you automatically, dropping them in to "buckets" of font sizes. This makes it simple to loop through them (like with a foreach) and output your tags with a little help from some CSS. You can even specify how many buckets you want it to fill (how many different tag values to get and compare).

Escaping quotes or other meta characters in SQL can be painful unless you get lucky with your quoting style. [...] Even with PHP's "Heredoc" syntax something will need escaping, but with PHP 5.3's new "Nowdoc" syntax no escaping is needed.

The only difference between HEREDOC and NOWDOC is that the initial keyword (like the first END in this statement: <<<'END' text here END;) that can make worrying about complex quoting rules a thing of the past.

There's some good advice in there, and I thought it'd be a good idea to quickly add a bit more detail about the separate approaches that Mike raises.

He goes over the APC caching, memcache, the "gzip trick", the "Not Modified" header and optimized SQL statements.

He also mentions one thing that Mike didn't mention - a split between static files (no PHP needed) and their dynamic cousins. Having a more pure Apache (no PHP installed) can help give a minute jump in speed that, depending on the size of the site, could really add up from a user's perspective.

Josh [Eichorn] argued at the time that dealing directly with the database was a better option. [...] His argument won me over, and until this past week I've viewed that as probably the most sane way to go. [...] Now, what started out as the simplest solution has morphed into this unrecognizable mishmash of SQL, code and convention.

He points out some of the issues that this sort of approach can bring up and how the Repository patten can help to make it a bit more manageable. It makes it simple to add the parameters needed for the query (via filters).