Very Computer

There are several tables that require a starting time period and an
ending time period.  Right now, that time period consists of a quarter
and a year, although that can change in the future.

From a normalization perspective, I think I should have a separate
TimePeriod table and link that table to the other tables that need
time periods.  That will result in two joins each time we want to link
the TimePeriod table with another table (one join for StartingPeriod
and one join for EndingPeriod).  But how will that affect performance?
 From a performance perspective, should we just have the time period
fields in each of the tables where that data is needed?

Quote:> There are several tables that require a starting time period and an
> ending time period.  Right now, that time period consists of a quarter
> and a year, although that can change in the future.

> From a normalization perspective, I think I should have a separate
> TimePeriod table and link that table to the other tables that need
> time periods.  That will result in two joins each time we want to link
> the TimePeriod table with another table (one join for StartingPeriod
> and one join for EndingPeriod).  But how will that affect performance?
>  From a performance perspective, should we just have the time period
> fields in each of the tables where that data is needed?

There are two questions here:
 1) What is the best relational schema for my application?

 2) How will a particular option be too expensive for my application?

You asked the second question, which no one but you can answer, and didn't
ask the first which.

David

Eventually, this data is going to feed into an OLAP cube using a star
schema.  I figured that adding time periods to the other tables
instead of normalizing a separate TimePeriod table would make it
easier for me to "flatten" out the data into a star schema later.
However, I'm not too sure if that's a good idea now.