Hi, I think you both took "need to deal with" to mean you have to "write code to deal with". A one in E38 or there chance doesn't mean you have to have E38 records for it to happen. Think of a dice: long term probability tells us it is one in six of any particular number yet that number can come up on the very first throw (oh craps). "Dealing" with that means looking at what damage can happen. If it's just one customer transaction failing, that's probably acceptable to most people. If it is someone's details being completely over written with no audit trail for recovery then that's probably not acceptable in a lot of cases. You may just let it throw an exception, but you shouldn't let it blindly over-write.
|-----Original Message----- |From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- |boun...@ozdotnet.com] On Behalf Of Craig van Nieuwkerk |Sent: Monday, 6 February 2012 12:03 PM |To: ozDotNet |Subject: Re: Making an application that uses identity keys occassionally |connected | |I am sure GUID collision detection code would be a good example of YAGNI. | | |On Mon, Feb 6, 2012 at 11:56 AM, Heinrich Breedt <heinrichbre...@gmail.com> |wrote: | | | 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" |<bill.mccarthy.li...@live.com.au> 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet- | |boun...@ozdotnet.com] 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 |<http://www.codeproject.com/Articles/32597/Performance-Comparison- |%7CIdentity-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 | | | |
