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
Newsletter
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

  • Part 4: Multi-Agent Orchestration — Pairing Goose With Quarkus Flow State Machines
  • A Field Guide to AI Agent Frameworks
  • Delegated Transport, Forked Authorization: Where Chat and AI-Agent Integrations Actually Break
  • Why Spark Executors Leave Cores Idle on YARN: A Packing Model for Executor Sizing

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  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
·
Jul. 03, 15 · Opinion
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
26.9K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

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

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • 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