Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

The NOT FOR REPLICATION parameter determines whether a new identity value for the new database
is assigned when the column is published to another database (via replication), or whether it keeps its
existing value. There will be much more on this at a later time.
ROWGUIDCOL
Chapter 5: Creating and Altering Tables
Briefly, replication is the process of automatically doing what, in a very loose sense,
amounts to copying some or all of the information in your database to some other
database. The other database may be on the same physical machine as the original,
or it may be located remotely.
This is also replication related and, in many ways, is the same in purpose to an identity column.
We’ve already seen how using an identity column can provide you with an easy way to make sure
that you have a value that is unique to each row and can, therefore, be used to identify that row. However,
this can be a very error-prone solution when you are dealing with replicated or other distributed
environments.
Think about it for a minute — while an identity column will keep counting upward from a set value,
what’s to keep the values from overlapping on different databases? Now, think about when you try to
replicate the values such that all the rows that were previously in separate databases now reside in one
database — uh oh! You now will have duplicate values in the column that is supposed to uniquely identify
each row!
Over the years, the common solution for this was to use separate seed values for each database you were
replicating to and from. For example, you may have database A that starts counting at 1, database B starts
at 10,000, and database C starts at 20,000. You can now publish them all into the same database safely —
for a while. As soon as database A has more than 9,999 records inserted into it, you’re in big trouble.
“Sure,” you say, “why not just separate the values by 100,000 or 500,000?” If you have tables with a large
amount of activity, you’re still just delaying the inevitable — that’s where a ROWGUIDCOL comes into play.
What is a ROWGUIDCOL? Well, it’s quite a bit like an identity column in that it is usually used to uniquely
identify each row in a table. The difference is to what lengths the system goes to make sure that the
value used is truly unique. Instead of using a numerical count, SQL Server instead uses what is known
as a Unique Identifier. While an identity value is usually (unless you alter something) unique across time,
it is not unique across space. Therefore, we can have two copies of our table running, and can have them
both assigned identical identity values for what are different rows. While this is just fine to start with, it
causes big problems when we try to bring the rows from both tables together as one replicated table. A
unique identifier, sometimes still referred to as a GUID, is unique across both space and time.
GUIDs (or, more commonly today, UUIDs — which look the same and do a better job at performing the
same task) are in widespread use in computing today. For example, if you check the registry, you’ll find
tons of them. A GUID is a 128-bit value — for you math types, that’s 38 zeros in decimal form. If I generated
a GUID every second, it would, theoretically speaking, take me millions of years to generate a
duplicate given a number of that size.
GUIDs are generated using a combination of information — each of which is designed to be unique in
either space or time. When you combine them, you come up with a value that is guaranteed, statistically
speaking, to be unique across space and time.
127