<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
SQL Server 2008 - General
»
UniqueIdentifier as a Primary Key
34 posts, Page 1 of 4
1
2
3
4
»
»»
UniqueIdentifier as a Primary Key
Rate Topic
Display Mode
Topic Options
Author
Message
alanspeckman
alanspeckman
Posted Wednesday, September 12, 2012 2:51 PM
Valued Member
Group: General Forum Members
Last Login: Yesterday @ 7:13 AM
Points: 62,
Visits: 385
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
ScottPletcher
ScottPletcher
Posted Wednesday, September 12, 2012 4:31 PM
Ten Centuries
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 3:56 PM
Points: 1,324,
Visits: 1,778
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)
One man with courage makes a majority. Andrew Jackson
Post #1358253
alanspeckman
alanspeckman
Posted Wednesday, September 12, 2012 8:08 PM
Valued Member
Group: General Forum Members
Last Login: Yesterday @ 7:13 AM
Points: 62,
Visits: 385
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
Jeff Moden
Jeff Moden
Posted Wednesday, September 12, 2012 9:28 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 3:06 PM
Points: 32,930,
Visits: 26,816
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 "
R
ow-
B
y-
A
gonizing-
R
ow".
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."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1358316
Eugene Elutin
Eugene Elutin
Posted Thursday, September 13, 2012 3:24 AM
SSCrazy
Group: General Forum Members
Last Login: Yesterday @ 10:39 AM
Points: 2,556,
Visits: 4,398
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
alanspeckman
alanspeckman
Posted Thursday, September 13, 2012 8:36 AM
Valued Member
Group: General Forum Members
Last Login: Yesterday @ 7:13 AM
Points: 62,
Visits: 385
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
ChrisM@Work
ChrisM@Work
Posted Thursday, September 13, 2012 8:49 AM
SSCertifiable
Group: General Forum Members
Last Login: 2 days ago @ 9:27 AM
Points: 5,618,
Visits: 10,990
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
Lynn Pettis
Lynn Pettis
Posted Thursday, September 13, 2012 9:04 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 11:18 AM
Points: 21,633,
Visits: 27,490
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
Sean Lange
Sean Lange
Posted Thursday, September 13, 2012 10:15 AM
SSCrazy Eights
Group: General Forum Members
Last Login: Yesterday @ 1:17 PM
Points: 8,641,
Visits: 8,273
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
Post #1358694
ScottPletcher
ScottPletcher
Posted Thursday, September 13, 2012 10:38 AM
Ten Centuries
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 3:56 PM
Points: 1,324,
Visits: 1,778
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)
One man with courage makes a majority. Andrew Jackson
Post #1358706
« Prev Topic
|
Next Topic »
34 posts, Page 1 of 4
1
2
3
4
»
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
