When I began to work on replication a few years ago, I was convinced that Identity Range Management was only made available in recent SQL Servers for legacy purposes as, prior to SQL Server 20开发者_高级运维00, the GUID type field did not exist and most primary keys were built on autoincrement fields.
I already saw some of these databases 'at work', and I can say that managing these Identity Ranges in a complex replication topology can be a real PITA, with guaranteed headaches and all-night-long debugging sessions.
I have just read here that Identity Range Management was still proposed as default with SQL Server 2008, followed by this other question on Best Practises and Identity Range Management where #mwolfe02 reaches the conclusion that, in some situations, users cannot insert data in the database unless they are granted db owner's right!
Disturbing, isn't it. So, with the exception of legacy databases, why should someone use Identity Range Management with SQL Servers? In a more generic way, why would someone promote any predetermined\autoincrement identification method in a database?
I guess one of the reasons to continue to use identity values is because of the disadvantages of using GUIDs as primary keys in a database, which is documented here GUIDs as PRIMARY KEYs.
I personally have never worked with a complex replication topology and have always used integers when setting up replication. I manage the identity ranges by adjusting the increment value of the identity function, so if I have two servers in replication I would have odd numbers on one and even numbers on the other and increment by 2. The same setup applies with multiple servers, the increment set equal to the number of servers.
I would also start my identity range at the lowest number for an integer (-2,147,483,648 to 2,147,483,647) as there is a lot of values that don't get used as integer identity columns are more often than not started at one. Even if you have 20 servers involved that still gives you quite a range of values to use.
精彩评论