Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

UniqueIdentifier as a Primary Key Expand / Collapse
Author
Message
Posted Wednesday, September 12, 2012 2:51 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, August 5, 2014 8:44 AM
Points: 87, Visits: 546
Is it ever considered a best practice to use a UniqueIdentifier(GUID) as a primary key?

Is there ever a case where you would want to use a GUID as a PK?

I watched Paul Randals excellent Myth #6 on his Pluralsight's Myths and Misconceptions course and he talks about using the NewSequentialID() function to assign a sequential GUID for clustered indexes, to avoid page framentation and maximize page density.

There are alot of opinions, I just wondered what you all thought of GUIDs as PK.
Post #1358221
Posted Wednesday, September 12, 2012 4:31 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:49 PM
Points: 2,044, Visits: 3,062
There is NO case where I would ever want to use a GUID as a clustered key column.

It would have to be THE ONLY WAY POSSIBLE for me to consider it.

The performance damage is just way too severe.


SQL DBA,SQL Server MVP('07, '08, '09)
"In America, every man is innocent until proven broke!" Brant Parker
Post #1358253
Posted Wednesday, September 12, 2012 8:08 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, August 5, 2014 8:44 AM
Points: 87, Visits: 546
What prompted me to question this was my coworker said it was a best practice when showing me a database design. I remembered Paul's video from an earlier viewing but I didn't remember the details. So, I viewed it again and did the demo myself so I saw his point.

Is there a white paper or some reference material that states this as fact? Not that I don't believe you, and given what I saw in Paul's video and other blogs, no, I would not use a GUID as a PK. I just need to help someone understand this at work.
Post #1358294
Posted Wednesday, September 12, 2012 9:28 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 4:24 PM
Points: 36,995, Visits: 31,522
alanspeckman (9/12/2012)
What prompted me to question this was my coworker said it was a best practice when showing me a database design. I remembered Paul's video from an earlier viewing but I didn't remember the details. So, I viewed it again and did the demo myself so I saw his point.

Is there a white paper or some reference material that states this as fact? Not that I don't believe you, and given what I saw in Paul's video and other blogs, no, I would not use a GUID as a PK. I just need to help someone understand this at work.


Books Online says the following about NEWSEQUENTIALID, which might make it tempting to use...

Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique. When a GUID column is used as a row identifier, using NEWSEQUENTIALID can be faster than using the NEWID function. This is because the NEWID function causes random activity and uses fewer cached data pages. Using NEWSEQUENTIALID also helps to completely fill the data and index pages.

... but look at that again. If you ever need to bounce the machine, "the GUID can start againn from a lower range". That's not a good thing to do with a clustered index which is what most PK's end up being.

Also, something to be aware of... Books Online is actually incorrect about GUIDs being globally unique (and MS has admitted that fact although I'm on the wrong machine right now to be able to provide the link). While the probability of running across duplicate GUIDs across multiple machines is very slim (and I do mean incedibly slim), GUID's in SQL Server are no longer guaranteed to be unique if more than one machine is involved. SQL Server now uses Type 4 GUIDs which are nothing more than pseudo-random numbers and there's no guarantee that two machines can't generate the same number. The old Type 1 GUIDs that SQL Server used to generate were guaranteed to be unique even between machines provided that things like the MAC address (IIRC) for the machine was different.



--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1358316
Posted Thursday, September 13, 2012 3:24 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, August 26, 2014 7:27 AM
Points: 2,836, Visits: 5,067
alanspeckman (9/12/2012)
Is it ever considered a best practice to use a UniqueIdentifier(GUID) as a primary key?
...


Nowadays, it's not considered as the best practice. However, there are cases where the use of GUID's for PK is justified. Please note, usually in these cases other columns/keys would be selected for table clustered index (PK is not clustered).
Old days, back when for insert operation Sybase/SQLServer used to lock whole pages, it was a practice sometime to use GUID's (or other random numbers) for PK and having clustered index on it for tables which were subject for often simultaneous inserts from concurrent users (lets say Call Centre systems for example).
Also, note the Jeff M post, GUID's generated by SQL have higher probability of re-occurrence when generated by two different machines as they now Type-2 instead of Type-1. That will give you an idea where is justifiable to have GUID's as PK - it's only now viable option if you really need to generate key in application layer. There you can still generate type-1 GUIDs.





_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!"
(So many miracle inventions provided by MS to us...)

How to post your question to get the best and quick help
Post #1358424
Posted Thursday, September 13, 2012 8:36 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, August 5, 2014 8:44 AM
Points: 87, Visits: 546
I appreciate your experience and knowledgable answers on this somewhat minor subject I raised here. In scanning blogs/forums, I see on other topics, like using special characters in your naming standards or not, that opinions can vary.

I will look into BOL for the text. I'm just wondering if there is a more athoritative source that mainly says what not to do, from acedemia, the SQL Team, or even Oracle.
Post #1358615
Posted Thursday, September 13, 2012 8:49 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:49 AM
Points: 7,234, Visits: 13,719
ScottPletcher (9/12/2012)
There is NO case where I would ever want to use a GUID as a clustered key column.

It would have to be THE ONLY WAY POSSIBLE for me to consider it.

The performance damage is just way too severe.


Quite right too - but would you use a GUID as a PK?


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
Exploring Recursive CTEs by Example Dwain Camps
Post #1358626
Posted Thursday, September 13, 2012 9:04 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 5:56 PM
Points: 23,343, Visits: 32,076
Jeff Moden (9/12/2012)
alanspeckman (9/12/2012)
What prompted me to question this was my coworker said it was a best practice when showing me a database design. I remembered Paul's video from an earlier viewing but I didn't remember the details. So, I viewed it again and did the demo myself so I saw his point.

Is there a white paper or some reference material that states this as fact? Not that I don't believe you, and given what I saw in Paul's video and other blogs, no, I would not use a GUID as a PK. I just need to help someone understand this at work.


Books Online says the following about NEWSEQUENTIALID, which might make it tempting to use...

Creates a GUID that is greater than any GUID previously generated by this function on a specified computer since Windows was started. After restarting Windows, the GUID can start again from a lower range, but is still globally unique. When a GUID column is used as a row identifier, using NEWSEQUENTIALID can be faster than using the NEWID function. This is because the NEWID function causes random activity and uses fewer cached data pages. Using NEWSEQUENTIALID also helps to completely fill the data and index pages.

... but look at that again. If you ever need to bounce the machine, "the GUID can start againn from a lower range". That's not a good thing to do with a clustered index which is what most PK's end up being.

Also, something to be aware of... Books Online is actually incorrect about GUIDs being globally unique (and MS has admitted that fact although I'm on the wrong machine right now to be able to provide the link). While the probability of running across duplicate GUIDs across multiple machines is very slim (and I do mean incedibly slim), GUID's in SQL Server are no longer guaranteed to be unique if more than one machine is involved. SQL Server now uses Type 4 GUIDs which are nothing more than pseudo-random numbers and there's no guarantee that two machines can't generate the same number. The old Type 1 GUIDs that SQL Server used to generate were guaranteed to be unique even between machines provided that things like the MAC address (IIRC) for the machine was different.




A little more information regarding NEWSEQUENTIALID() from BOL (MSDN version):


You can use NEWSEQUENTIALID() to generate GUIDs to reduce page contention at the leaf level of indexes.
Each GUID generated by using NEWSEQUENTIALID() is unique on that computer. GUIDs generated by using NEWSEQUENTIALID() are unique across multiple computers only if the source computer has a network card.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1358636
Posted Thursday, September 13, 2012 10:15 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:41 PM
Points: 13,315, Visits: 12,182
ChrisM@Work (9/13/2012)
ScottPletcher (9/12/2012)
There is NO case where I would ever want to use a GUID as a clustered key column.

It would have to be THE ONLY WAY POSSIBLE for me to consider it.

The performance damage is just way too severe.


Quite right too - but would you use a GUID as a PK?


Not if I can avoid it.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1358694
Posted Thursday, September 13, 2012 10:38 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:49 PM
Points: 2,044, Visits: 3,062
Sean Lange (9/13/2012)
ChrisM@Work (9/13/2012)
ScottPletcher (9/12/2012)
There is NO case where I would ever want to use a GUID as a clustered key column.

It would have to be THE ONLY WAY POSSIBLE for me to consider it.

The performance damage is just way too severe.


Quite right too - but would you use a GUID as a PK?


Not if I can avoid it.



Exactly.

Almost always avoidable. For example, assign each site a unique code. Then the unique site code + unique sequence from that site will always be unique. Just remember that the site code in the value IS JUST TO MAKE THE VALUE UNIQUE, NOT to tell you what site it originated in or resides at; that type of information should be additional columns, just like all the other data.


SQL DBA,SQL Server MVP('07, '08, '09)
"In America, every man is innocent until proven broke!" Brant Parker
Post #1358706
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse