Unfortunately, the article glossed over quite a bit. The Devil in these details is a much bigger beast. For example, including the effective dates as part of the primary key will not prevent duplicates as others have mentioned. Granted, we cannot see check constraints or triggers in his design, but one could image data such as:

PromotionId, ProductId, Start, End

1, 1, 1/1/2009, 1/31/2009 5:00 PM

1, 1, 1/1/2009, 1/31/2009 11:59 PM

1, 1, 1/2/2009, 1/31/2009 11:59 PM

I have dealt with temporal designs in the past and in one case a design that required *two* sets of dates on numerous data elements. The single greatest headache is that adding temporal fields will break normal data integrity rules such as the intent of primary keys as above mentioned. In order to prevent having two active promotions for the same product and promotion, you must use triggers to enforce data integrity rules which account for overlap.

A temporal design most definitely is the right fit in certain circumstances but it should be clear that it must be a decision in which the stakeholders account for the additional development cost. That cost rears its head in every query (and thus report) against the data.

Temporal designs can get quite complicated fast. For example, I can see a requirement for an effective date range for both the promotion and the product's membership to the promotion. "This promotion is only for June. Product X will not be available as part of that promotion until June 15 due to supplier issues." etc.