RE: Making an application that uses identity keys occassionally connected

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 |wrote

RE: Making an application that uses identity keys occassionally connected

://www.sqldownunder.com/> www.sqldownunder.com 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

RE: Making an application that uses identity keys occassionally connected

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

RE: Making an application that uses identity keys occassionally connected

V4 guid's don't use nic ids or timestamps anymore On Feb 6, 2012 11:04 AM, "Greg Keogh" wrote: > >The problem with guids is they are not guaranteed to be unique: > > Hang on! I thought that was their major selling point. They are supposed to > be sufficiently sparse and random over the 128 bits t

RE: Making an application that uses identity keys occassionally connected

>The problem with guids is they are not guaranteed to be unique: Hang on! I thought that was their major selling point. They are supposed to be sufficiently sparse and random over the 128 bits that the chance of collisions is really, really vanishingly small. NEWSEQUENTIALID is supposed to re-see

Re: Making an application that uses identity keys occassionally connected

ds. >> >> >> |-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 appl

RE: Making an application that uses identity keys occassionally connected

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/Pe

RE: Making an application that uses identity keys occassionally connected

|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 G

RE: Making an application that uses identity keys occassionally connected

Folks, most people here seem to dislike Guids as primary keys. The article via Bill is quite sobering, showing that NEWID is a shocking performer, but INDENTIY and NEWSEQUENTIALID perform similarly well

RE: Making an application that uses identity keys occassionally connected

Tony mentions >> Of course, because you can synchronise with the single-source-of-truth in a batch anyway, both have strategies that will work. If you choose guids, I think you need to separate out the data that you're adding from the client vs reference data, so you don't make the mistake of imp

Re: Making an application that uses identity keys occassionally connected

Hi Kirsten, >From my experience, using GUIDs as surrogate primary keys works fine in development where sample data is only thousands of rows. It bites viciously in production where we have millions of rows and deep dependencies. Int keys are still surrogate keys but seem to offer better performanc

Re: Making an application that uses identity keys occassionally connected

I think the sync framework will crack a fruity if the Guid is not the PK. On Thu, Feb 2, 2012 at 8:50 AM, Greg Keogh wrote: > Kirsten has lots of tables already created with traditional PK IDENTITY > columns, so I’m guessing that converting the PKs would be a nightmare. > Perhaps a compromise is

RE: Making an application that uses identity keys occassionally connected

Kirsten has lots of tables already created with traditional PK IDENTITY columns, so I'm guessing that converting the PKs would be a nightmare. Perhaps a compromise is the answer: add an indexed Guid column to those tables that might find it useful in sync processing. That Guid is effectively "stamp

Re: Making an application that uses identity keys occassionally connected

Depending on your use cases and scale requirements, GUIDs a good choice. An engineer at one of the companies I work with did a good chunk of research and we resolved to use integers for our use cases: http://www.google.com.au/webhp?ion=1#sclient=psy-ab&q=guids%20index%20fragmentation My $0.02 is

Re: Making an application that uses identity keys occassionally connected

+1 for guids. I use them as PK in a sync framework app. On Thu, Feb 2, 2012 at 6:59 AM, David Ames wrote: > ** ** > > If your only talking a small number of clients you can play with > seed/increment values. > > ** ** > > Eg: > > Node 1: Seed = 1, Increment = +2 > > Node 2: Seed = 2,

RE: Making an application that uses identity keys occassionally connected

If your only talking a small number of clients you can play with seed/increment values. Eg: Node 1: Seed = 1, Increment = +2 Node 2: Seed = 2, Increment = +2 Node 3: Seed = -1, Increment = -2 Node 4: Seed = -2, Increment = -2 You can also assign ranges (and run the risk of running out of numbe