>>>>
>>>>I'd definitely recommend creating a date calendar table - basically one row per calendar day, with many columns to describe that day (what week, what fiscal month, what calendar month, etc.) in as many terms as the business needs...
>>>
>>>For me this would be additional maintenance. In my application Monday of a Month and how it relates to the Week in a Year is used quite a lot. And these values change from year to year. I prefer to have the program calculate it on-the-fly rather than having to rebuild such a table every year.
>>
>>Please don't take this personally - I strongly disagree. Most places create a date calendar table/date dimension and build it out a few years in advance, and many have a script to generate it. It is a superior practice.
>>
>>I will post some code later for an example of how to build one out. Seriously, you shouldn't have an application calculating this on the fly. There are better ways to do that.
>
>What is a real technical reason that calculating on the fly is not as good as having a table? (aside from the fact that you don't like it :))

Here's one (of many)

Accounting for seasonality

I did client work for a company that sold fish products. During the weeks of Lent (different time period each year), they wanted to track sales in Lent week 1, Lent week 2, "across" years.

By placing a Lent column in the date table across years, it was easy.

Get the picture? :)

Imagine having to do that in code...all the time.

There's easily a "Baker's Dozen" of reasons why calendar tables are superior :)