July 29, 2013 at 3:57 pm
Hi everyone,
Does anybody know any cases/example that we need to use UNIQUE KEY instead of PRIMARY KEY? I understand that UNIQUE KEY can allow one NULL value in the data, but I don't know the reason for that. Why do we need that extra NULL VALUE? And, When do we need it?
Thanks!
Kaz
July 29, 2013 at 5:07 pm
Kazarf (7/29/2013)
Does anybody know any cases/example that we need to use UNIQUE KEY instead of PRIMARY KEY? I understand that UNIQUE KEY can allow one NULL value in the data, but I don't know the reason for that. Why do we need that extra NULL VALUE? And, When do we need it?
A Primary Key is a Referential Integrity constraint, that's why it should never allow a Null value.
On the other hand, an Unique Index is an index that doesn't allow for duplicate values but it is not a Referential Integrity constraint.
In my opinion, you do not "need" and extra Null Value - it is just allowed to be there even if I would never ever allow for Null Values on a Unique Index, it is not elegant and a symptom that something is wrong with the way data was modeled.
_____________________________________
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.July 29, 2013 at 6:44 pm
Thank You so much! ^^
July 30, 2013 at 3:35 am
Good one Paul 🙂
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
July 30, 2013 at 3:56 am
You can also create multiple unique indexes on the same table, but you can have only one primary key.
A unique index can also be filtered, while a PK cannot.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 30, 2013 at 4:17 am
Koen Verbeeck (7/30/2013)
You can also create multiple unique indexes on the same table, but you can have only one primary key.A unique index can also be filtered, while a PK cannot.
I am not clear with this statement_
A unique index can also be filtered, while a PK cannot
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
July 30, 2013 at 4:22 am
http://msdn.microsoft.com/en-us/library/cc280372%28v=sql.100%29.aspx
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 30, 2013 at 4:44 am
GilaMonster (7/30/2013)
http://msdn.microsoft.com/en-us/library/cc280372%28v=sql.100%29.aspx
Thanks Gail for the useful link 🙂
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
July 30, 2013 at 5:01 am
On the other hand, an Unique Index is an index that doesn't allow for duplicate values but it is not a Referential Integrity constraint.
Paul,what exactly you mean by that..
As we can have referential integrity constraint column referring on unique key columns also...
Pramod
SQL Server DBA | MCSE SQL Server 2012/2014
in.linkedin.com/in/pramodsingla/
http://pramodsingla.wordpress.com/
July 30, 2013 at 5:17 am
psingla (7/30/2013)
On the other hand, an Unique Index is an index that doesn't allow for duplicate values but it is not a Referential Integrity constraint.
Paul,what exactly you mean by that..
As we can have referential integrity constraint column referring on unique key columns also...
Yes, but then you are creating a foreign key on top of some columns who happen to be part of unique index. The index itself has nothing to do with referential integrity.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 30, 2013 at 8:04 am
A pretty common use of unique keys is when you have an artificial primary key for a table, the single most common example is the identity field, but you still need to define the logical key (and any other alternate keys) in order to prevent duplicate storage within the table.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 30, 2013 at 12:51 pm
Grant Fritchey (7/30/2013)
A pretty common use of unique keys is when you have an artificial primary key for a table, the single most common example is the identity field, but you still need to define the logical key (and any other alternate keys) in order to prevent duplicate storage within the table.
True dat. A common scenario is in data warehousing, where you have a clustered index on the surrogate key of a dimension, and a unique index on the business key of the dimension.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 31, 2013 at 9:48 am
Koen Verbeeck (7/30/2013)
Grant Fritchey (7/30/2013)
A pretty common use of unique keys is when you have an artificial primary key for a table, the single most common example is the identity field, but you still need to define the logical key (and any other alternate keys) in order to prevent duplicate storage within the table.True dat. A common scenario is in data warehousing, where you have a clustered index on the surrogate key of a dimension, and a unique index on the business key of the dimension.
+1 excellent example.
_____________________________________
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.Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply