August 19, 2008 at 9:46 am
Hi,
Our fact table has 40M rows. Currently we have a identity column as PK, since we can't build a unique key with the columns we have in our table. We never use this column in any case, so basically the data is sorted on a way that we never use, but it was the only way to get a unique key on the table. Is it a good idea to have this kind of PK for a big table? I figure out it was kinda useful for reorg/defrag purpose….
Any advise will be helpful.
Thanks for your help
Rem
August 19, 2008 at 10:47 am
You said FACT table therefore you are talking about a Data Warehouse environment.
You do not use a natural PK on Data Warehouse, by using surrogate keys you are doing the right thing.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.August 19, 2008 at 11:06 am
The surrogate keys will help to keep every rows unique, right? This can be done with the current identity column I have in place. Therefore, I can drop all constraint attach to it, this is correct?
Thanks,
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply