Archives of the TeradataForum

Message Posted: Wed, 08 Jan 2003 @ 20:07:01 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

All,

As an example:

We have about 6 types of calendars (4-4-5, 5-4-4, Gregorian, modified 4-4-5, etc.) we store in our warehouse. As we continue to implement in new countries, we will probably come across some new calendar requirements. Seemingly, the cleaner solution is to create a generic period table with calendar type a part of the primary key and another table which defines all parent\child relationships in a recursive manner; however, for reporting purposes, it is easier to work with "snowflaked" tables (Day table with attributes and relationship to week, Week table with attributes and relationship to month, etc.) Of course, I could create views of the generic calendar table to make them look like "snow-flaked" tables or denormalized, flat tables; however, the datatypes of my Calendar levels will probably vary from the datatype we use to store data in the "fact" tables. This would result in poor query performance.

Which is the preferred solution? 1 generic period table or many tables? 1 generic period table with many views? Reporting or Storage?

Thanks,

Clay

	<Prev	Next>		<<First	<Prev	Next>	Last>>