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.
: 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
|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
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
V4 guid's don't use nic ids or timestamps anymore
On Feb 6, 2012 11:04 AM, Greg Keogh g...@mira.net 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
that uses identity keys occassionally
connected
Folks, most people here seem to dislike Guids as primary keys. The
articlehttp://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
/ 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
Folks, most people here seem
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
] On
Behalf Of Kirsten Greed
Sent: Thursday, 2 February 2012 7:52 AM
To: 'ozDotNet'
Subject: Making an application that uses identity keys occassionally connected
Hi All
I am interested in making my application occasionally connected.
My app uses SQL Server and the tables have identity keys (auto
Of *Kirsten Greed
*Sent:* Thursday, 2 February 2012 7:52 AM
*To:* 'ozDotNet'
*Subject:* Making an application that uses identity keys occassionally
connected
** **
Hi All
I am interested in making my application occasionally connected.
My app uses SQL Server and the tables have
*Sent:* Thursday, 2 February 2012 7:52 AM
*To:* 'ozDotNet'
*Subject:* Making an application that uses identity keys occassionally
connected
** **
Hi All
I am interested in making my application occasionally connected.
My app uses SQL Server and the tables have identity keys
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
12 matches
Mail list logo
