Skip to main content

Query Pivot in MySQL

Basically this blog post is about dynamic columns in MySQL queries.  Since you can't run "pivot" queries in MySQL, how do you write queries that return an arbitrary number of columns (perhaps based on the number of rows in another table)?

The answer is simple: you can't... at least not in a single query.  The best way to do this is to run two queries and generate the SQL for the 2nd query based on the results of the 1st query.

Imagine this table of product sales:

ProductIDCustomerIDUnit Sales
1120
1250
2120
2270
2390

Maybe you want your result set to look like this...
ProductIDCustomer 1Customer 2Customer 3
120500
2207090

Write this query first:

SELECT CustomerID, CustomerName FROM `customers`

Store the results into $rows.  For each $row, append this string to $fields:
", SUM(CASE WHEN CustomerID=$row[0] THEN `Unit Sales` ELSE 0 END) AS $row[1]"

Then... write this query:

"SELECT ProductID $fields
FROM `sales`
GROUP BY ProductID"

Done.  This pattern is not recommended, but sometimes you might find this to be useful for custom reporting.  Also, I can guarantee that this performs WAY better than multiple joins.  Plus, MySQL places a limit on the maximum number of table joins you can have in a query... at the time of this writing, the limit is 61.  Cheers!

Comments

Popular posts from this blog

Wedding Prediction - October, 2013

Carla and I are planning on getting married sometime in October next year.  We need to pick a date, and that decision may  involve some science and mathematics.  :) For example, we want the weather to be nice.  To be more precise, we'd like the high temperature for the wedding day to be between 60 and 80 degrees Fahrenheit.  Obviously, we have both lived in Ohio our entire lives, and we have a pretty good idea of what the weather will be like.  We both hypothesised that October was a "hit or miss" sort of month; it could be cold, or it could be nice. But, for me, a simple hypothesis was not enough; I really wanted to know the probabilities of decent weather based on historical weather data.  Many websites on the Internet (i.e. almanac.com) charge you to review historical weather data, but Carla and I discovered a cool page on cleveland.com that provided exactly what we wanted.  I loaded the historical temperature data from 1903 to 2011 f...

Web Browsers You Should Support

As a web developer, generally speaking, you should consider supporting the following browsers (at the time of this writing): Chrome (latest) - the browser that sets the bar for the others; you should be using it and supporting it Internet Explorer 9+ - the browser that finally caught up with the times a bit; basically, a Chrome wannabe.  I still say that IE sucks... even if it really doesn't anymore.  Yes... I'm sour about IE8 and below. Internet Explorer 8 - the old, sad browser that we sadly still have to support for a while.  CSS 3 is not well-supported here, so we use projects like CSS3 PIE or whatever.  By the way... IE8 sucks.  I can't wait until this comes off of the list. Firefox (latest) - the browser that was once awesome and has sadly suffered recently because it's slower than Chrome... but hey, lots of people still use it. Safari (latest) - Watch out for Safari as more iPhones, iPads, Macs, and more overly-priced Apple products flood the ...

Data Persistence in Various Databases

This blog post will cover the varying levels of data caching and data persistence provided by various operating systems and database systems. Cache  - A device placed in front of another storage device that is used for temporary storage of data.  The use of a hardware cache is often transparent to the end user and is generally smaller, faster, and less persistent than the backed storage device.  Rather than reading/writing from/to a slower storage device (i.e. a hard disk), we read/write from/to the cache (i.e. RAM, NVRAM, etc.). Reading from a cache is simple.  If the datum we requested is in the cache, we simply read it from the cache.  If not, we need to retrieve the datum from the storage device and place it into the cache (often a much slower operation). There are different policies when we write to the cache, though... Write-Through Cache Policy  - When using this policy, writing over the cache also writes over the data on the backed storage d...