Re: Simplifying db queries
Date: Sat, 05 Mar 2005 13:35:29 GMT
"David Cressey" <david.cressey_at_earthlink.net> wrote in message
> "cruiserweight" <bayon86_at_yahoo.com> wrote in message
> > Nope. I was wrong. On second look the first entry provided what is
> > probably a decent explanation. My db skills, however, are no where near
> > the level. I guess I'm effed.
> More about Calendar Dimension Tables:
> Take look at this article by Ralph Kimball, and pay special attention to
> figure 2.
To my dismay, I see that the file type of ".jhtml" in the above link got split apart in the process of posting the link on the newsgroup. If you just click on the link as it appears, you don't get anything.
Here's an attempt to post it again:
Just in case this fails as well, here's how I found the article: I did a google search on "Calendar Dimension Table", and followed the third or fourth link it found, to the article by Ralph Kimball in Intelligent Enterprise magazine.
Thinking it over, here's how I would summarize the point I'm driving at:
Coming up with a calandar table like the one Kimball illustrates can be a great way of simplifying queries, even if you don't intend to follow any of the other design ideas that Kimball's "star schema" design would suggest. All the calendar's quirks about religious holidays, and leap years, and years with 53 paydays in them, and all that, can be stored in one table, rather than spread all over the application. And building that table from scratch, with a program, is eminently feasible.
Once you've seen how useful a dimension table is, you may want to build more of them, or maybe not. A reporting database with a calendar table, and all the other tables in a more classic form, is still very useful. Received on Sat Mar 05 2005 - 14:35:29 CET