DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • How to Store Text in PostgreSQL: Tips, Tricks, and Traps
  • JSON-Based Serialized LOB Pattern
  • Architecture and Code Design, Pt. 1: Relational Persistence Insights to Use Today and On the Upcoming Years
  • SQL Commands: A Brief Guide

Trending

  • LLM-Powered Deep Parsing for Industrial Inventory Search
  • Zero-Downtime Deployments for Java Apps on Kubernetes
  • Stop Debugging Glue Jobs Manually: Building an Agentic Observability Layer for Data Pipelines
  • AI Paradigm Shift: Analytics Without SQL
  1. DZone
  2. Data Engineering
  3. Data
  4. The UUID Discussion

The UUID Discussion

UUID really start coming in handy is when you start synchronizing data across servers.

By 
Lieven Doclo user avatar
Lieven Doclo
·
Jul. 03, 15 · Opinion
Likes (0)
Comment
Save
Tweet
Share
26.8K Views

Join the DZone community and get the full member experience.

Join For Free

Those who are familiar with databases and persistence have probably had the same discussion like I have had a couple of times over the last couple of years:

Do you use numeric or String values as an UUID?

Having done a lot of distributed, multi-tenant development, my stance on this is very clear: I prefer String. Or better said, I prefer UUIDs.

Granted, it’s easier to remember user with id 345 than user with id 03a3a8b1-002c-4f7b-aefb-1691cc274718, but that argument goes out the window when your ids start going in over 10000, in which case you’ll copy paste them and end up with the same amount of effort you would have to do with a UUID.

Where UUID really start coming in handy is when you start synchronizing data across servers. See, most systems that rely on numeric values for an id do so with an autogenerated value. Which means you have no control over which id will be given to a certain entity in your system and therefor makes it a complete mess to transfer data across servers.

For example, say you have an entity A with id 3 and an another entity B that has a foreign key to A. You want to move A and B to another server. Now guess what happens: A gets an new id and you need to manually translate the link from B to A in order to get the correct link. If you forget to do this, you’ll either have a missing foreign key or worse, B may suddenly have a link to an entirely different entity… With UUIDs, you can just transfer the data as is without having to worry about remapping foreign keys.

However, every time I brought this up in the past, the same comment was given: “But you can have duplicates!”. Well, for those who like math: if you generate a billion UUIDs every second for the next 100 years, you have a 50% chance of having a single collision. To put this even more in perspective, if you would limit yourself to the range of a 32-bit integer, the chance to have a collision is 1.6 * 10-27. If you don’t like those odds, I suggest you don’t leave the house (meteorite strike), get in your car (random car accident) or eat something (food poisoning).

So stop using numeric ids and start using UUIDs.

Relational database Database 32-bit Data (computing) Data Types Links Strings Collision (computer science) Transfer (computing)

Opinions expressed by DZone contributors are their own.

Related

  • How to Store Text in PostgreSQL: Tips, Tricks, and Traps
  • JSON-Based Serialized LOB Pattern
  • Architecture and Code Design, Pt. 1: Relational Persistence Insights to Use Today and On the Upcoming Years
  • SQL Commands: A Brief Guide

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook