#Boost uuid generator example Offline#

You can, of course, generate it yourself and set it on your entity object before persisting it. When doing that, you need to decide how you want to generate the UUID value.

If you decide to use UUIDs, you can, of course, also persist them with Hibernate. You should, therefore, decide carefully if you want to use UUIDs or numeric IDs and discuss it with your database administrator. It’s 4 times larger than a numerical ID and can’t be handled as efficiently. On the other hand, the UUID also has some disadvantages.

#Boost uuid generator example Offline#

That’s why UUIDs have become popular in microservice-based architectures or when developing offline clients. Each component can generate its own UUIDs, and there will not be any conflicts.

You don’t need any of this when using a globally unique UUID. That obviously creates some effort that slows down the generation of your primary key values. Other approaches, e.g., a clustered database or any other horizontally scaled number generator, require communication between the nodes. This makes that sequence the single source of failure. In most cases, this is a sequence for each table that’s managed by your database. If you use the typical numerical ID that gets incremented for each new record, you need to generate all IDs by the same system component. The main advantage of a UUID is its (practical) global uniqueness which provides a huge advantage for distributed systems. UUIDs, for example, have gained some popularity over recent years. But that doesn’t mean that a primary key has to be a number. Most developers prefer numerical primary keys because they are efficient to use and easy to generate. Get access to all my video courses, 2 monthly Q&A calls, monthly coding challenges, a community of like-minded developers, and regular expert sessions.