All geek questions in one place

Switching from nHibernate HiLo to GUID

Can i switch from HiLo to GUID.comb? As far as I can tell, the latter combines the advantage of HiLo, namely the management of the client side of Ids instead of having to call the database to get a new identifier, with the advantage that it is impossible to complete work with identifiers.

We are currently facing issues with large HiLo identifiers such as Int32 (it was supposed to be Int64, but this is more than the WTF of my predecessor) is not large enough. We can upgrade to Int64, but that means we will run into the problem later, and not earlier.

Since identifiers should not be meaningful, switching to a GUID seems logical. However, since I never tried to use such a switch, I was wondering if anyone here could help me evaluate the impact that this could have.

+4
source share
1 answer

In fact, switching to int64 is usually enough. Remember that you add 32 more bits that multiply the id space by +/- 2 billion . Are you sure this is not enough?

As for switching to Guid, it includes (assuming a live DB):

  • Creating new pk / fk columns
  • Filling pk columns with new values
  • Filling columns fk based on old
  • Delete current foreign and primary keys
  • Removing old pk / fk columns
  • Create new primary and foreign keys
  • Changing the types and generators of id properties (this is the only step using .net code)

In any case, while the GUID provides “unlimited” identifiers and is easy to generate, it also has the disadvantage of being twice as large (128 bits) and a little more difficult to manipulate manually (i.e. you will depend on copy and paste when debugging

+6
source

Source: https://habr.com/ru/post/1337949/

More articles:


All Articles