Using SQL PIVOT and UNPIVOT

Comments

I learned about a pair of SQL keywords I didn’t know existed before. I suppose I shouldn’t have been so surprised this ability existed in SQL since I knew it existed within Excel spreadsheets, but it really saved the day this last week. I’m speaking of the PIVOT and UNPIVOT SQL keywords.

This last week I needed to track down some data inconsistencies in our database by joining a few view model tables. These tables are populated by event handlers that denormalize the relevant data from events into a view model table that serves the needs of a specific part of the UI. In one particular view model table, it made sense to arrange the data points specific to each US state as columns on a single row. This allowed for a grid-based UI that enables batch operations on many rows at one time. A second view model table was intended for a different use case and was designed so that the state-specific data points became a one-to-many relationship across multiple rows and only two columns for the key-value pair of the US state and its associated data point value. These were two of the tables I needed to join together during my database inquisition.

At this point I figured I was stuck, as I couldn’t see a sensible way to join two tables designed so contrary to each other for the purposes of joining. I tried to think of any ways to dynamically join tables on a column name in one table specified by the value in the other table’s row. I knew I was heading nowhere fast, so I asked our DBA for some ideas. He informed me of the PIVOT and UNPIVOT keywords in SQL as one option to solve the problem. We reasoned that even though it may not be the most efficient feature, the likelihood of it proving to be a performance bottleneck would be essentially non-existent (given that the entire size of the data set was relatively small, on the magnitude of hundreds or thousands of rows instead of millions of rows). And so I gave it a go.

I will now describe an example scenario in order to illustrate how I used the UNPIVOT feature to join two tables that didn’t seem at all compatible. The goal will be to join a table representing what US states each product is available for sale within to a table representing how many of each product are being sold in each state. We will call the first table ProductAvailability and give it an integer identity column named Id, an integer column named ProductId, and then 52 bit columns indicating the availability status of the product in each of the 50 US states, the District of Columbia, and Puerto Rico. These columns will be named by their two letter abbreviations of AK through WY. The second table we will call ProductSales and it will also have an integer identity column named Id and an integer column named ProductId. In addition it will have a string column (specifically char(2)) named StateCode and an integer column named TotalSales.

The unpivoting of the ProductAvailability table to prepare it for joining can be done like so:

    SELECT
      Unpivoted.ProductId,
      Unpivoted.StateCode,
      Unpivoted.IsAvailable
    FROM ProductAvailability
    UNPIVOT
    (
      IsAvailable FOR StateCode
      IN (AK,AL,AR,AZ,CA,CO,CT,
          DC,DE,FL,GA,HI,IA,ID,
          IL,IN,KS,KY,LA,MA,MD,
          ME,MI,MN,MO,MS,MT,NC,
          ND,NE,NH,NJ,NM,NV,NY,
          OH,OK,OR,PA,PR,RI,SC,
          SD,TN,TX,UT,VA,VT,WA,
          WI,WV,WY)
    ) AS Unpivoted

The interesting part is obviously the UNPIVOT clause. Here we are declaring a list of column names to unpivot and also naming two new columns in which to place the old column’s name and value (StateCode and IsAvailable respectively). The result is that instead of having one row of 54 columns for each product, we now have 52 rows of three columns to describe the exact same availability of the product. But with this second schema, we can more easily join with the ProductSales table.

Here is an example of such a query where we are trying to find the products which have no sales in a state for which it is marked as available for sale:

    SELECT
      ProductStateAvailability.ProductId,
      ProductStateAvailability.StateCode
    FROM
    (
      SELECT
        Unpivoted.ProductId,
        Unpivoted.StateCode,
        Unpivoted.IsAvailable
      FROM ProductAvailability
      UNPIVOT
      (
        IsAvailable FOR StateCode
        IN (AK,AL,AR,AZ,CA,CO,CT,
            DC,DE,FL,GA,HI,IA,ID,
            IL,IN,KS,KY,LA,MA,MD,
            ME,MI,MN,MO,MS,MT,NC,
            ND,NE,NH,NJ,NM,NV,NY,
            OH,OK,OR,PA,PR,RI,SC,
            SD,TN,TX,UT,VA,VT,WA,
            WI,WV,WY)
      ) AS Unpivoted
      WHERE Unpivoted.IsAvailable = 1
    ) AS ProductStateAvailability
    INNER JOIN ProductSales
      ON ProductSales.StateCode = ProductStateAvailability.StateCode
      AND ProductSales.ProductId = ProductStateAvailability.ProductId
    WHERE ProductSales.TotalSales = 0

I hope you find the PIVOT and UNPIVOT SQL keywords just as helpful as I did if you ever find yourself in a bind with two tables that are seemingly impossible to join.

FubuMVC Webinar - Compositional and Convention-based Web Development

I just gave a webinar yesterday for JP Boodhoo’s Develop With Passion® webinar series on Compositional and Convention-based Web Development with FubuMVC. The recorded session is now posted online with a slew of referenced and related links. I apologize for the sound quality and will make corrections if I get another chance to do another webinar/screencast. Here is the link to the recording:

http://webinars.developwithpassion.com/webinars/3

I didn’t mention this in the screencast but before we began switching our company’s production website to FubuMVC, we first devised a way to get the benefit of FubuMVC Behavior Chains while still on the ASP.NET MVC framework. Please feel free to read more about that successful venture at Bob Pace’s blog post on the MvcToFubu project.

FubuMVC Behavior Chains - the BMVC Pattern

For the last several months at work, we have been gradually migrating our production website to use the .NET open source FubuMVC web framework. Before committing to a whole new infrastructure for our site, some brilliant talent on our team decided to improve our experience on the ASP.NET MVC framework by integrating in one of FubuMVC’s most compelling features, behavior chains. Bob Pace originally blogged about the process in a two part blog post series (part 1 and part 2); since then, he has created a packaged solution called MvcToFubu which he just recently started another blog post series about.

Behavior chains are by far my favorite feature of FubuMVC. I believe they single-handedly revolutionized our use of the MVC pattern in a web environment. In fact, I like to think of it as a whole new pattern, the BMVC Pattern (I was told by a coworker that the ‘B’ should stand for “Better”, and while that’s true, I’ll stick with “Behaviors”). No, I’m not sincerely trying to coin yet another design or architectural pattern buzzword. However, I am most sincerely not joking when I say behavior chains add a whole new dimension to how I design web architectures. I find myself creating composable pipelines of cohesive, testable components in lieu of monolithic controllers and actions.

What are Behavior Chains?

Have you ever looked at your controller actions and thought “Man, there’s a lot going on here!” (validation, authorization, transactions, ORM setup, logging, caching, etc.)? If you haven’t, I urge you to take a conscious look at your controller actions and try to identify code that doesn’t directly relate to the purpose of the page (or sub-view of the page). Shouldn’t there be a way to move some of this secondary infrastructure code out of our controller actions and have it be applied conventionally to the correct actions/routes? Yes, and this is exactly what Behavior Chains are meant to accomplish, the ability to create composable pipelines of reusable behavior nodes for each route in your site.

Behavior chains can be built up in any order you want for each route via Conventions and Policies, which are extension points that allow you to inspect and modify the entire Behavior Graph that was built by FubuMVC during startup bootstrapping. The behavior graph is the modifiable collection of all behavior chains in the site, initially built with just a few default behavior nodes for each route. A typical behavior chain by default usually has an ActionCall node (representing the call to a controller action) and an Output node (often a tie-in to a view rendering engine, but can also be JSON or anything else). Other behavior nodes can be sprinkled into the pipeline in any order in front of or in between the ActionCall and the Output nodes. As mentioned before via the use of Conventions and Policies, it is common practice to filter your list of behavior chains using LINQ extension methods and then add a specific behavior node into the matching chains at a specific location in the chain. This truly elevates coding to conventions to a new level; some of the filtering criteria regarding controller actions that you may come up with could be as follows:

  • Action method names that contain a certain word.
  • Actions methods that are located in a particular controller or namespace.
  • Action method signatures that contain an input/output model that implements a specific interface.
  • Action method signatures that contain an input/output model that contains a property of a certain type or have a particular C# attribute applied to it.
  • So on, so forth…whatever you can dream up!

One more aspect of behavior chains that is important to point out is the logistics in how behavior nodes are chained together. The chains are not merely a linked-list of behavior nodes that are traversed linearly. Instead the makeup of the chains is better conceptualized to be an outer behavior node wrapping around an inner behavior node, which is then itself an outer node wrapped around another inner node, and so on. In fact, the FubuMVC developers like to refer to this chaining architecture as the Onion Layer Model or the Russian Doll Model (conjuring up a mental image of the nesting Russian doll toy called a matryoshka doll or a babushka doll). When an outer behavior node has finished executing it’s logic, it can then optionally execute it’s inner behavior node logic (or stop the behavior chain entirely in order to return early with a response, an error, or even transfer to a different route and behavior chain). One of the key advantages that this wrapping architecture can afford is the ability for an outer behavior to run additional logic or clean up code after all inner behavior nodes have completed (i.e., transactions can be committed, connections can be closed, sessions can be disposed, etc.).

How does this change the way I code my controllers?

I find that my controller actions are much thinner and more focused on the base case and the successful code path. All the exceptional code paths and edge cases have been identified and deal with by the other behavior nodes in the chain, prior to my action call being invoked. My action call can now focus on the essential logic that differentiate this route from others. That essential logic doesn’t get lost anymore in the necessary infrastructure code that should be a secondary concern. And all of this logic can be broken up into cohesive, reusable components within a flexible request/response pipeline that can be built up automatically by coding to whatever conventions you deem beneficial. Behavior chains really do add a whole new first-class citizen to the MVC design pattern. Do yourself a favor and check out the MvcToFubu solution mentioned at the top of this post, and bring some FubuMVC behavior chain goodness to your ASP.NET MVC website. I think you might be as impressed as we were and yearn for the other killer features of FubuMVC as well.

Comments

Mike Murray
Thanks for thought! Perhaps I'll post on the mailing list and see what others think about it being involved in the FubuMVC documentation somewhere.
Rex
Great post, I didn't see this one when I was writing my post about authentication behavior. This is a great explanation of behavior chains in FubuMVC.

This would also be a great intro to behaviors for the fubumvc guides.

.NET Needs More Apprenticeships

It came to my attention recently that there are a few companies in other dev circles with all-star developers who give back to their communities by doing apprenticeship programs or open door programs at their workplaces. Basically the idea is to let people come into your workplace and pair program with them, sharing knowledge and best practices. I believe we need more of this sense of community going on in the .NET space. I’m sure I’ve probably overlooked something (or perhaps I’m about to spout off craziness and heresies), but it just seems like we should be able to work out the logistics to make this a reality.

The interesting thing is that this really isn’t a new concept in other professions. For example, the culinary world has had the idea of staging for quite a while. Sometimes it’s a final part of an interview process and other times it’s just to swap techniques and recipes. As mentioned above, I was recently informed of a few dev companies that have taken this idea to our profession. In the Rails community, Hashrocket has an apprenticeship program where you can apply to be a part of their team for a week and soak in some of the awesome skills and techniques they possess. It appears they vet their candidates a bit to ensure they get the right kind of people coming in who are motivated and ready to learn, and also because the code being worked on is for real Hashrocket projects for their clients. In the Node.js space, Joyent has a program called Office Hours where devs can register for free in advance to bring in something to work on with a Joyent employee at end of work day and get their feedback & expert advice. They provide snacks, drinks, and a comfortable work environment.

I think these ideas are brilliant and foster real community among developers. Although this idea alone can improve the interview and hiring process, I think it can go further than that to help our profession mature in the sharing of best practices and proven techniques. For most .NET companies out there, I’m willing to bet there are few legitimate roadblocks that would prevent instituting programs like these. Being completely honest with yourself, how much of what you work on each day is top secret intellectual property that is core to the success of your company and absolutely cannot be seen by outsiders? Even if there are parts of your code that should not be seen by strangers, I’m sure there are projects and tasks to be done on the other parts of code that will still prove instructive for your invited guests. I encourage our dev community to do whatever it takes to make this happen: have the visitors sign non-disclosure agreements, interview and re-interview potential candidates to meet satisfactory requirements, don’t allow them to hook up thumb drives to your machine and steal your secrets, whatever! It doesn’t matter if it’s a week-long thing or a few hours; let’s realize we’re all in this together and build this community up to have a higher standard of software craftsmanship.

Develop With Passion Bootcamp Course - Denver 2011

A very talented coworker and I recently went to JP Boodhoo’s Develop with Passion bootcamp training course (previously known as Nothin but .NET). I had originally heard of the course from Dave Tchepak who attended the course nearly two years ago. This blog post is a wrap-up of my thoughts and feelings about the course itself, JP Boodhoo as the instructor & experienced craftsman, and the .NET development community in general.

My prior impressions of the course from what I had read was that I would be in awe of JP’s coding and design skills and very overwhelmed with the feeling that I didn’t really know how to code; also that I would get no sleep at all that week, going from early morning to past midnight every day. I had also heard from a previous course member (off the record) that JP’s organization and direction with course material was a bit disorganized back then (luckily this has changed significantly since he had taken the course). I was really excited to see some good BDD in action, get my TDD passion ignited again (I had actually mentioned on twitter recently that my motivation for test was waning as of late), and see JP’s mad Vim skills (since I have gotten into that the last few months).

Overall, I was pleasantly surprised with the fulfillment of most of my positive expectations and initial impressions going into the course. JP’s personality and passion are infectious, and his teaching skills are pretty top-notch. The course material was well-structured and there was a clear direction for what we hoped to cover throughout the week (and yet, he was still flexible enough to be able to briefly entertain an off-topic direction the students wanted to take the course). He stayed true to the advertised 9am-9pm every day no matter what. He said that when he did the late nighters with previous courses, people came back the next day with little sleep and trashed as far as coding & learning capabilities go.

Watching him code so efficiently is quite a treat. He automates anything he does more than once so that a particular task doesn’t ever get in his way and hold him back the next time. His AutoHotkey scripts and automation tools that he has put together are absolutely incredible. He briefly touched the mouse two times the entire week, and it only for when one of his programs or Windows VM was wigging out. Screens and dialogs flew by so fast, you could tell he wasn’t going to let any UI (even Visual Studio) get in the way of his productivity to code. He mentioned he will be open sourcing some of his scripts that he uses to keep his development environment consistent across OS platforms. Definitely cool stuff.

As far as JP’s actual coding/design skills, I am absolutely floored. He certainly understands C# and .NET well. But it’s his Object-Oriented design skills that blew us away. I’ve realized I don’t really know OO design. I think too mechanically about the implementation of the solution instead of focusing on breaking down the problem into smaller manageable chunks. His TDD skills (both Top Down Design and Test Driven Development) are amazing. I’ve never been a fan of the TDD samples and intros I’ve seen (where the instructors do the absolute dumbest thing to make the test pass; JP admitted that style didn’t jive with him either). I’ve always thought that Behavior Driven Development and Top-Down Design were the way to go if I were to have tests drive my designs (or have tests at all for that matter; I’m still having trouble finding enthusiasm for tests written after development for modules and units). So it was great to see a master at that particular craft. It made me excited to use tests as a tool to guide my OO design, behavior discovery, and problem solving.

Some of you may recall that I had previously investigated BDD, Machine.Specifications, and Top-Down Design a year and a half ago doing the Anagram Code Kata. I think I can recognize better design and responsibility break-up and assignment nowadays. I likely will blog on these subjects again this year with new & improved passion and knowledge.

There was one sad takeaway for me personally from the course, which was a sense of disappointment in the .NET development community in general. Giving myself some time since the course to really think it through, I’m realizing I’m probably being too tough on our community, as I know each Dev community out there suffers from it’s own set of problems. But I don’t want to excuse our shortcomings either; rather, I would like to point them out so that we can focus on them and root those weaknesses out. I think our community in specific is unique in that there is a big shot company that dictates the direction our community should take, sometimes taking credit for all the innovation. Things are improving lately no doubt; it appears Microsoft is listening more and more and trying to let outsiders get involved and contribute.

But we as .NET devs need to step up and take matters into our own hands, we need to take better control of the code we write and encourage best practices within the realms of our responsibilities and influence. I believe many .NET shops rely on the tools sent down from above so heavily that we don’t really solve problems anymore. JP’s focus on problem solving and code katas from the course attack this deficiency at its core. I do somewhat blame our university Computer Science programs for not teaching real OO (a great discussion on formalism versus hermeneutics in a book I highly recommend, Object Thinking), but at some point we have to take what we were given and no matter our current standing, focus on sharpening our skills through practice and continuous learning. It boils down to individual responsibility for our current skill set and progression as a software craftsman. JP’s course does a terrific job of waking you up to that realization and inspiring you to be a better professional at your craft.

I have a few takeaways from the course that I’ll publicly spell out now. First, I (and hopefully our whole team) need to better understand design patterns and have them become integral to our code discussions. JP was all about efficiency in keystrokes and related dev tasks, and it seems natural that our language and code discussions could benefit from more efficient communication using design pattern terminology to convey a lot about a specific design concept in only a few words. Second, I hope that I (and our team again) can really put our tests to work for us, helping us recognize the problem to be solved or the behavior that needs to be captured, and then guiding us toward a simple solution. The third takeaway is related to that last part, and that is to have simple solutions that are distributed across simple object implementations (focusing on behaviors) that adhere to SOLID principles. It appears the key is to not focus on implementation specifics until the very last responsible moment; if done right, the implementations to create should be so clear cut and trivial, almost spelled right out in the tests themselves. It’s hard to put into words, but it seems crucial to focus first on the collaborators needed while designing code at the higher levels, finding ways to offload as much responsibility as possible (at least that’s what it felt like) onto dependencies that have yet to be designed and implemented. Designing Top-Down in this way gave such simple and elegant solutions that were totally extensible and adhered to the Open/Closed Principle better than any other code I have ever seen before. Perhaps as I blog more about this, I’ll be able to better put this style of coding into words (especially as I try to better understand it myself; it all seems so magical still!).

Overall, a great course that I highly recommend to all. JP has mentioned doing a similar course in Ruby, which I personally find especially interesting, given the same design/coding techniques would seem to run against a lot less friction compared to the heavy reliance on interfaces and mocking that C# require.

Stay tuned as I try to put some of this stuff into practice!