Probably worth saying that using guids as a primary key is not for everyone. The key is bigger, so that has a size and performance impact on all your indexes and foreign keys, and as a clustering key it means new records are scattered throughout the file rather than being appended to the tail, leading to logical fragmentation.
(But if you need to replicate, synchronize or pre-allocate the key offline in the app tier they can make a lot of sense) From: Michael Ridland Sent: Friday, May 2, 2014 7:37 PM To: ozDotNet Guids are also great for offline distributed clients. AutoInc numbers will be a thing of the past. On Friday, May 2, 2014, Jano Petras <[email protected]> wrote: Hi Anthony, Guids are easiest way forward - due to their uniqueness and native support by the DB engine. The only time I would consider using something else would be if there was a requirement for those unique row IDs to be 64bit integers for example or if there is a storage space concern - in this case I would consider using horizontal partitioning and allocating range of IDs to different instances reserving each one with a predefined range of values. On 2 May 2014 16:16, <[email protected]> wrote: Anyone doing database replications, are you using guids? Have any recommendations or experiences? I don’t usually use guids but working on systems that may need to scale, so thinking of switching to guids to avoid any future scalability issues Thanks in advance J Anthony
