|
Comments
|
Bill Johnson on
4/12/2010
This was really helpful. I've had the debate with myself many times. Good input!
|
|
|
I had already done similar; VERY good follow-up.
|
|
|
Very informative.
|
|
|
Awsome Awsome Awsome..
|
|
|
Good info that I needed to hear...
|
|
|
GUIDs go on forever? Really?
|
|
|
A very informative video. You briefly mentioned generating the GUIDs programmatically, and I think that this needs to be as big a consideration as the Int/GUID question. If the value (Int or GUID) is being used only as a unique value to identify and index that table alone, and will NOT be referenced in any other tables, then using the database to auto-fill the uniqueidentifier field is not a problem. But if that value is going to be referenced by another table, then you must generate it programmatically and not let the database set the values. One main reason is that it will be difficult to replicate the tables while preserving the unique values and having them work across the indexes. If these columns are defined as standard Int fields, or text fields containing your program-generated GUID, then you can just copy the records and preserve the values. If the column is set to have the database generate the values, then you are at the mercy of that table’s whims. And your Customer ID in your primary database may not be the same in your backup one. Disclaimer: I'm a programmer and not a DBA, so my tendencies are biased in that direction.
|
|
|
Thanks for another excellent short video.
I was wondering whether partioned tables would be a factor in deciding the type of primary key column.
|
|
clement huge on
4/12/2010
Average.
I am sorry but Guid is really not usefull anymore on primary key. I disagree with any use on Guid. It is the past definitely!
|
|
|
We use int and bigint for most primary keys. Now using ASP.NET for web work i was thinking of using uniqueidentifiers for my order/orderdetails tables to enahnce security, especially with login ID's. Thanks for the info.
|
|
|
Very well presented. Carried wealth of information. The page size access to determine score is a vital tool.
|
|
|
excellent Video
|
|
|
Excellent video
|
|
|
I didn't really follow why calling newid() on the server caused page splits, but generating a guid on the client didn't.
|
|
|
Never gave primary keys much thought. Gives something to think about.
|
|
|
Go Andy!!!
|
|
Martin Miller on
4/13/2010
Excellent overview of benefits and drawbacks of uniqueidentifier and identity keys. Thanks Andy.
|
|
|
Learn something new everyday!
|
|
|
nice and make my easier to explain those nerdy .Net architects and smart developers on this issue who argues with me all the time
|
|
|
Excellent video. Thanks.
|
|
|
Excellent perspective! Thank you!
|
|
|
It is worth noting the difference between relatively static versus high transaction tables on the impact of fragmentation on performance when using a non-sequential GUID. I've had to go to much lower fillfactors but have achieved stable performance in 2000 without the benefit of sequential GUIDs. As for small lookup tables I agree that GUID is not the way to go. But I will still side with a natural key over an integer if possible. The problem with integer keys, to me, is that they have no intrinsic meaning...much like your point regarding GUIDs. Otherwise very informative and it gave me a couple of new considerations.
|
|
Cosmin Tornea on
4/15/2010
ok
|
|
|
Excellent topic and very good presentation.
|
|
Clayton Smith on
4/19/2010
Superb presentation. Great work Andy.
|
|
|
Great Video.
|
|
|
Muito bom
|
|
|
Excellent commentary, Andy. Good call to call the DBA and app dev buy in from the start. I think a lot of DBAs forget the convenience (and reduction of the round trip) when talking about GUIDs. I also think that a lot of app devs don't understand the physical foundation of the database files. I'm going to circulate to our team because reinforcing this knowledge doesn't hurt. Thanks again for the wonderful presentation!
|
|
|
Great!
|
|
|
Nice overview. Thanks.
|
|
|
People, get a reality check on this. There is no good reason to choose a GUID as a primary key! It's all about the numeric values baby! Think about the joins you gotta make in the long run when your tables start growing large. I disagree with the narrator here, the larger the column length to join on, the slower your joins are gonna work.
|
|
|
I appreciate the discussion on when to use each type of index, and the impact they will have both positive and negative. There is no such thang as a general rule fitting all situations.
|
|
|
very informative. awesome job. back to the basics :)
|
|
|
Good explanation...thanks Andy
|