Question

Is it possible to switch from HiLo to GUID.comb? As far as I can tell, the latter combines the advantage of HiLo, namely managing Ids client-side instead of needing a call to the DB for getting a new Id, with the advantage that it’s impossible to run out of Ids.

Currently we are running into problems with HiLo generating Ids so big, that Int32 (this should have been Int64, but that’s more of a WTF of my predecessor) isn’t big enough. We can change to Int64, but this just means we will run into problem later rather than sooner.

As the Ids do not need to be meaningful, a switch to GUIDs seems logical. However, as I’ve never attempted such a switch, I was wondering whether anyone here could help me assessing the impact something like that could have.

Answer 1

Actually, switching to int64 is usually enough. Remember that you’re adding 32 more bits, which multiplies the id space by +/- 2 billion. Are you sure that’s not enough?

Regarding switching to Guid, it involves (assuming a live DB):

• Creating new pk / fk columns
• Filling the pk columns with new values
• Filling the fk columns based on the old ones
• Dropping current foreign and primary keys
• Dropping old pk / fk columns
• Creating new primary and foreign keys
• Changing the id property types and generators (this is the only step involving .net code)

Anyway, while GUID provides “unlimited” ids and it’s easy to generate, it also has the disadvantage of being twice as big (128 bits) and slightly harder to manipulate by hand (i.e. you’ll depend on copy&paste when debugging