As we progress towards the Ides of March, one of my best friends-who-I’ve-never-met, Jimmy May, notes our annual transition to Daylight Savings Time, in a post he generously concludes with a link to one of this very blog’s oldies but goodies.
In his blog’s title, Jimmy humbly refers to himself as Jimmy May, Aspiring Geek. Based on the reputation he earned with MCS and the A.C.E. team, I humbly suggest that his geekdom has arrived (no geek worth their salt would ever describe another geek as “fully formed;” along with their deep expertise, true geeks carry with them an abiding respect for their ignorance).
I first ran into Jimmy shortly before we discovered we have legions of mutual friends (several of whom have told me that we really need to meet each other), when a version of the post to which he linked which I circulated on an internal Microsoft discussion group caught his eye. In a discussion of implementing database support for global time zone conversions, I wrote (new emphasis):
Let me say at the outset that I have not yet encountered the “perfect” solution to this issue; there are simply too many variables to deal with this issue unambiguously and in its totality. For instance, there are several towns in the US state of Indiana where Daylight Savings Time is observed on one side of the street but not the other. An unambiguous solution would involve rendering a table of every street address in the world, including its time zone rules.
Jimmy and I began a correspondence which has blossomed into a wonderful pixel-based mutual admiration society (after several years, I believe we sat on our first-ever conference call a couple of months ago). My thanks to Jimmy for today’s link-love, and for previously familiarizing me with the surprisingly serpentine politics of bringing temporal consistency to the Hoosier State. The reference above was dated when I made it in June of 2006; it’s a measure of the post’s age that its description of the United States’ Daylight Savings Time algorithm is also no longer applicable.
Another rite of spring is proceeding in slightly altered form, as baseball’s spring training has been augmented (derailed?) by the triennial World Baseball Classic. Against that backdrop comes the following question from Bob Magee via the blog’s email feedback function:
You seem to be the perfect person to ask this question...
I'm trying to learn SSAS and I've been searching for a good example of a OLAP database that uses baseball statistics (I know... I should create one myself then I would really learn). Any good examples out that you know of?
Thanks for any help.
I’m still looking into this for you, Bob, but I can think of two places you might want to look. SABR (the Society for American Baseball Research) is the nexus for ground-breaking statistical research on the game; I’d be surprised if there weren’t OLAP cubes behind at least some of that work. For pure statistical volume, baseball-reference.com can’t be beat. I’m not sure what sort of database software they’ve got backing them up, but that would be another good place to look.
I share your contention, though, that you’ll learn the most if you build one yourself. If my to-do list weren’t already too long already, I’d consider adding it there..
I’ll keep looking.. and if any of you denizens of the Internets have any suggestions for Bob, please post them here.
The Equinox approaches.. and then Opening Day. Perhaps there’s hope after all..
this copyrighted material was originally posted at http://blogs.technet.com/wardpond.
the author and his employer are pleased to provide this content for you at that site, and via rss, free of charge and without advertising.
the author welcomes and appreciates links to and citations of his work. however, if you are viewing the full text of this article at any other website, be aware that its author does not endorse and is not compensated by any advertising or access fees you may be subjected to outside the original web and rss sites.