Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

DateTime as part of PK in FACT Table

DateTime as part of PK in FACT Table

DateTime as part of PK in FACT Table


Ok so I know generally its not good idea to have a DateTime column as your PK, however for my situation I believe it makes more sense than having a suggogate key in the Fact Table.

The reason are...

1) The data inserted to the fact table is always sequential. I.e. I would never insert date time value that is older than the last value already in Fact table. 2) The data time is not the only column of the PK (composite PK), The PK is of course itself and the dimension FK's surrogate key. 3) The way i be querying the data is nearly always based on time. 4) A surrogate key on the Fact table would tell me nothing about the row. Each row is already unique and to find that particular fact I would always filter on the Date time first and the values in the dimensions. 5) There is no seperate datetime dimension table. No requiremnet now of forseen to have named points in time etc.

Side notes - time will be in UTC and using SQL 2008 R2.

What im asking is giving the situation - what are the disadvantages to doing this? Will I come up against unforseen issues? Is this actaully a good thing to be doing when querying that data basck later?

Would like to know peoples view points on DataTime as first column of a composite PK.

Many Thanks


RE: DateTime as part of PK in FACT Table

I'm curious: what type of data are you storing and the granularity (minute, second?) Are you adding the datetime to enforce uniqueness?

Ties Blom

RE: DateTime as part of PK in FACT Table

I would be inclined to split your datetime field into two fields:
1) a date field declared as a NUMBER, formatted as YYYYMMDD (eq. 20111231)
2) a time field declared as a NUMBER, formatted as HH24MISS (eg. in range of 0-235959)

This way, your values can be used as surrogate keys, while retaining their appearance of dates and times.  Should you decide to add a date dimension table (and maybe a time dimension as well), you need not make any changes to your fact table. Only your queries would change to join to the date dimension.


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close