October 21, 2021 at 4:26 pm
I second the "nonwork_days" table, but I would make sure to design the reason code table well.
You would want to make sure that the reason code table has a reason code identifier, a reason code description, and a reason code location. The location may need to be broken up into multiple columns to handle country, state/province, and potentially city. This will allow you to quickly and easily account for holidays in the USA vs CANADA vs JAPAN vs CHINA vs etc.
Excellent point. Actually country and client_id are in our nonwork_days table, and others might need similar distinguishers. But extraneous things like a fiscal year, standard character representation, etc., should not be in this table.
You can denormalize and have the main calendars table indicate non-work days also by using a join to the nonwork_days table to update the calendars table. The nonwork_days table must control what is a work day or not.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
November 12, 2021 at 7:48 am
This was removed by the editor as SPAM
November 12, 2021 at 7:51 am
This was removed by the editor as SPAM
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply