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
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
SQL Server 2008 - General
»
Primary key or not to primary key, that is...
15 posts, Page 2 of 2
««
1
2
Primary key or not to primary key, that is the question
Rate Topic
Display Mode
Topic Options
Author
Message
Jeff Moden
Jeff Moden
Posted Wednesday, March 20, 2013 8:43 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 4:51 PM
Points: 32,923,
Visits: 26,811
Eugene Elutin (3/19/2013)
But, when you have NIC installed, it makes it unsecured, as it's based on the MAC address of NIC and can be predicted.
Just to be clear for other that may be reading this, "normal" GUIDs no longer use the MAC address and are nothing more than random numbers. Sequential GUIDs do.
The current "normal" GUIDs used by SQL Server are "Type 4" GUIDs, which are nothing more than a very large random number, and even Microsoft says that although the chance of duplicating one is still incredibly small, there's no longer a guarantee that they're globally unique. Best put a unique index on it if it's a key column.
I agree with the "scramble" on the sort, though. There is a "block" sort order but they don't sort GUIDs from left to right. I've not played with sequential GUIDs but I imagine that because of the way they sort, they're gonna cause fragmentation no matter what.
--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 #1433263
Lynn Pettis
Lynn Pettis
Posted Wednesday, March 20, 2013 8:52 AM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 2:23 AM
Points: 21,630,
Visits: 27,484
TheSQLGuru (3/20/2013)
tafountain (3/20/2013)
TheSQLGuru,
I did not intend to spark a debate :) but here are my responses.
TheSQLGuru (3/19/2013)
1) if you are worried with space, GUIDs have no place in your system.
This statement is a little unsubstantiated. GUIDs are fine, sure they're larger than INT but they fulfull requirements that an INT cannot. For example we need to maintain uniqueness across servers. A GUID does this for us. Yes, they have drawbacks but I would not totally exclude them as an option because of them.
TheSQLGuru (3/19/2013)
2) why aren't you using NEWSEQUENTIALID??
These do not provide uniqueness across tables, let alone across servers.
TheSQLGuru (3/19/2013)
3) Your PK on the parent does a clustered index on the NEWID, since you didn't specify one.
Is this a question or a statement? Not sure what you're trying to communicate.
TheSQLGuru (3/19/2013)
4) You are fragmenting the heck out of your nc indexes on those GUIDs.
Yes - this is very true. However most of the indexes are defragmented in under 30 seconds (most under 10 seconds) during our nightly maintenance.
TheSQLGuru (3/19/2013)
5) Did I mention that GUIDs SUCK yet?!? Oh, and for multiple systems, you can almost ALWAYS come up with a simple multi-part numeric arrangement that is guaranteed to be unique across all systems. I have used a tiny/smallint ServerID and integer identity construct at numerous clients to eliminate GUIDS they "HAD to have", always with GREAT effect.
Ok, now you have my interest :). I wouldn't mind understanding your implementation.
1) As I already said, you can (and I have several times) maintained uniqueness across multiple servers with an int identity and a separate ServerID field (tiny or small int) that is used as the compound PK for the table. Given that ServerA ALWAYS uses 1 for ServerID, ServerB ALWAYS uses 2 for ServerID, etc, you are GUARANTEED to NEVER get duplicate PK values with that 5 or 6 byte PK (instead of the SIXTEEN bytes of a GUID).
2) I believe you are wrong in stating that NEWSEQUENTIALID isn't UNIQUE. The only time it would not be is if there is no NIC on the server. Got many of those lying around?? I haven't seen one in the 20+ years I have been with databases, 15 of them as a SQL Server consultant. Here is the reference, which comes directly from SQL Server Books Online: http://msdn.microsoft.com/en-us/library/aa379322(VS.85).aspx
3) My "PK is clustered index" is a statement. If you simply define a PK on a table it is clustered by default unless you override that with explicit syntax to make it non-clustered.
4) It may not matter (much) on your system, but the extra bytes required for a GUID over other datatype(s) or compound keys REALLY make a difference on systems with any reasonable number of rows.
Regarding this:
3) My "PK is clustered index" is a statement. If you simply define a PK on a table it is clustered by default unless you override that with explicit syntax to make it non-clustered.
Or if you already have a clustered index defined on the table when you define a PK. The PK will be nonclustered if there is already a clustered index on a table.
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 #1433274
tafountain
tafountain
Posted Wednesday, March 20, 2013 9:04 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 9:59 AM
Points: 104,
Visits: 333
As far as the NEWSEQUENTIALID goes, SSCrazy hit most of the points I didn't elaborate on. We have multiple requirements and some of those include the application code generates the identifier before saving the record to the database. All in all, I agree from an implementation perspective an INT column defined with IDENTITY sounds more plausible but it, just like GUIDs, have thier own pro's and con's.
Post #1433285
Eugene Elutin
Eugene Elutin
Posted Wednesday, March 20, 2013 10:33 AM
SSCrazy
Group: General Forum Members
Last Login: Yesterday @ 10:39 AM
Points: 2,556,
Visits: 4,398
tafountain (3/20/2013)
As far as the NEWSEQUENTIALID goes, SSCrazy hit most of the points I didn't elaborate on. ...
Who are you calling SSCrazy, SSC Journeyman?
GUID's are evil! B-r-r-r-r-r!
_____________________________________________
"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 #1433337
tafountain
tafountain
Posted Thursday, March 21, 2013 12:54 PM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Tuesday, May 21, 2013 9:59 AM
Points: 104,
Visits: 333
Eugene Elutin (3/20/2013)
tafountain (3/20/2013)
As far as the NEWSEQUENTIALID goes, SSCrazy hit most of the points I didn't elaborate on. ...
Who are you calling SSCrazy, SSC Journeyman?
GUID's are evil! B-r-r-r-r-r!
Oops, I copied his title and not his name lol - Eugene.
Post #1433982
« Prev Topic
|
Next Topic »
15 posts, Page 2 of 2
««
1
2
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.