Posted by Erland Sommarskog on 10/18/32 11:29

--CELKO-- (jcelko212@earthlink.net) writes:
> The Calendar table is not just for this one problem. It is an
> auxiliary table that serves the ENTIRE schema. Think in terms of
> general, global code instead of handling each problem as a
> self-contained one-shot. A data model is a whole, not disjoint parts.
>
> So the ability to use a fiscal calendar is not required by your
> accouting department? Your Human Resources department does not care
> about holidays?

Tell me Celko, in your previous life when you sold vacuum cleaner's
at people's doors, were you really successful only because you were
so tiresome insisting that they bought one only to get rid of you?

We have no idea what business problem PromisedOyster has, so it's
quite pointless to cram that calender table down this throat.
Particularly, since when we know he does not have have privileges
to create tables anyway.)

And for that matter, our database has a dates table which is a single-column
table with all dates from 1990-01-01 to 2150-01-01. Simply your table of
numbers, but with dates. We need to be able to insert/update data into
historic tables over a date range. Holidays etc? Yes, there is table
for this as well, but it only has entries for Mon-Fri that are not
business days, and it's maintained by users. This table could never
serves as the date table that I mentioned previously, can you see why?



--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[Back to original message]