I reckon I will skip writing code that has a 1 in 10^38 chance of being needed On Feb 6, 2012 10:33 AM, "Bill McCarthy" <[email protected]> wrote:
> The problem with guids is they are not guaranteed to be unique: there's a > really large probability that they are unique. You still need to deal with > possible collisions. I'm guessing that NEWSEQUENTIALID is probably less > unique than machine generated guids. > > > |-----Original Message----- > |From: [email protected] [mailto:ozdotnet- > |[email protected]] On Behalf Of Greg Keogh > |Sent: Monday, 6 February 2012 11:28 AM > |To: 'ozDotNet' > |Subject: RE: Making an application that uses identity keys occassionally > |connected > | > |Folks, most people here seem to dislike Guids as primary keys. The article > |<http://www.codeproject.com/Articles/32597/Performance-Comparison- > |Identity-x-NewId-x-NewSeque> via Bill is quite sobering, showing that > NEWID is > |a shocking performer, but INDENTIY and NEWSEQUENTIALID perform similarly > |well. After reading that I am unlikely to use NEWID again. > | > | > | > |I would still like to hear convincing arguments against NEWSEQUENTIALID. > |Noonie says his DBAs rejected them (why?). Tony hates looking at them in > the > |debugger (that's not a convincing argument for me). Greg L says you might > as > |well get an INT instead (more details?). > | > | > | > |I hope you'll agree that there are times when you want to give rows an > |immutable primary key. Will you also agree that an IDENTITY INT is not > |immutable because it can change when rows move across databases or when > |rows are reorganised or reloaded. If this is so, how on earth do you stamp > your > |rows with an immutable key without using something like Guids? > | > | > | > |Greg > > >
