Jeff Moden (9/4/2012)

---

RBarryYoung (9/4/2012)

---

Jason-299789 (9/4/2012)

---

Jeff Moden (9/3/2012)

---

rka (9/2/2012)

---

DateKey has to be in the format YYYYMMDD

In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.

I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.

As for actually building the table... what have you tried that's not working?

Jeff I agree its pretty insane,

But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.

Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.

However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.

A "DW" is a data warehouse which is an OLAP-type database, and these rules and keys might make sense there, because an OLAP database has different goals than an OLTP database, and thus a different (though related) modelling methodology, and therefore a different set of normal rules.

An OLAP database is designed to facilitate reporting, at the expense of other things, like diskspace and being able to maintain the data in real-time. OLTP databases on the other hand are designed to facilitate real-time data updates while insuring consistency and still be able to report on the data.

Because of these differences in goals, OLAP databases will frequently have highly redundant multi-discriminating key structures, like the one you suggest, because they can greatly facilitate reporting and summarization. But they are an anethema to an OLTP database because they introduce all kinds of problems with maintaining the consistency of the data and keys when trying to incrementally keep it up-to-date in real time.

BWAA-HAAA!!!! Is that the long version for "storing dates as INTs or VARCHARs sucks"??? 😀