Home Page for the TeradataForum
 

Archives of the TeradataForum

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


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


Subj:   Modeling Question
 
From:   Claybourne Barrineau

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>>
 
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 15 Jun 2023