Tuesday, March 20, 2012

Replication and uniqueidentifier

Abdul,
it's better not to use GUIDs for PKs as they are too
large (4x the size of an integer).
Identity columns can be used in merge replication - you
can enable sql server to maintian the ranges to ensure
they never overlap. Have a look at the article properties
of a table containing identity columns before it is
subscriber to, and there is a checkbox on the identity
range tab. The easiest way is tp ensure that the ranges
are so wide that there will never be any need for them to
be updated.
HTH,
Paul Ibison (SQL Server MVP)[vbcol=seagreen]
Thank you Paul for your reply. I used int primary key to avoid using GUID
because of speed issues but did not foresee that we would use replication
later on. Since there is a limit on using a integer key there is a possiblity
that all the numbers could get taken as there are a lot of rows, and many
rows get inserted daily.
Maybe a string key could work but GUID's are guaranteed to be unique
according to Microsoft. Maybe I can alleviate the speed issue by using a
combination of indexes and selecting only those records which need to be
viewed in the front end. This was the plan but I wanted to make sure that
GUID columns would not be affected when implementing merge replication as I
thought it adds its own guid column.
-Abdul Rauf
"Paul Ibison" wrote:

> Abdul,
> it's better not to use GUIDs for PKs as they are too
> large (4x the size of an integer).
> Identity columns can be used in merge replication - you
> can enable sql server to maintian the ranges to ensure
> they never overlap. Have a look at the article properties
> of a table containing identity columns before it is
> subscriber to, and there is a checkbox on the identity
> range tab. The easiest way is tp ensure that the ranges
> are so wide that there will never be any need for them to
> be updated.
> HTH,
> Paul Ibison (SQL Server MVP)
>
|||Abdul, integers go from -2billion to 2 billion so you're only going to have
a problem if the data spans >4billion!
If that is the case, you could partition the data using a composite key,
with one column as a subscriber identifier.
HTH,
Paul Ibison (SQL Server MVP)[vbcol=seagreen]

No comments:

Post a Comment