|
|
Posted by corey lawson on 10/21/05 06:07
Erland Sommarskog wrote:
> corey lawson (corey.lawson@ayeteatea.net) writes:
>
>>Erland Sommarskog wrote:
>>
>>
>>>The two tables serves different purposes. The table with all the dates
>>>puts no attributes on the dates, and is only a help table for some
>>>operations. The other table lists only holidays. Neither that table
>>>has any other data beside the primary key, beside auditing data. But
>>>there is an important difference between the two tables, let's see if
>>>you can spot it!
>>
>>Yes, using the second table with just holidays is a PITA. Flagging dates
>>in the calendar as various holidays is far easier to use.
>
>
> No. Well, in the case you only care about one country, it is. We need
> to keep track of non-business days in several countries.
>
>
>
>
So you add other fields to help identify different holidays, right?
At the very least, Chicago celebrates Kasmir Pulaski Day (it's an
official Chicago holiday, in that schools and city offices are closed.
I'll refrain from making any derisive comments about Hizzoner Daley).
As far as quickly populating a calendar table, sometimes it's just
quicker to fire up Excel, start in A1 with "1/1/2005", and drag it down
to A65535 or so to autofill the dates forward, and then import it into a
table.
It's just so much easier working with a calendar table like this (theta
joins work pretty dang good), so that for the person who asked, the DBA
should be able to find SOMEWHERE in the database, even in the master
database (gasp! shock! horror!). If done right, it'll be static for
quite some time (years), and should be relatively obvious for a database
geek to realize if it's getting near the end of time to extend it again.
Besides, if you're using non-calendar accounting periods (i.e., 4-4-5,
13-wk qtrs, etc), it's about the only way to make them sane, that is, if
you're not an accountant.
Navigation:
[Reply to this message]
|