DEV Community

Eloquent UUIDs.

Kati Frantz on April 10, 2018

In this tutorial, I'm going to show you how and why to use uuids as your primary keys in your eloquent models. What are UUIDs? A Uuid (...

Read full post

jakebman • Apr 10 '18

Please don't use a random algorithm to generate UUIDs. You're defeating the exact purpose for which they were created.

Yes, 128 bits of randomness are not likely to collide (beating out all lotteries ever), but you know what's better than "not likely to collide"? "Guaranteed by construction to never collide with another UUID, ever"

GUIDs are designed to be unique, not random

Kati Frantz • Apr 11 '18

Hey, thanks a lot for your reply @jakebman . What's your suggestion for substituting randomness with uniqueness ?

Albi Abdyli • Apr 11 '18 • Edited

//change 
$table->incrementing('id');
//to
$table->uuid('id');

laravel.com/docs/5.6/migrations#cr...

Aleksi Kauppila • Apr 11 '18

You should check this library out: github.com/ramsey/uuid. It's very popular.

Albi Abdyli • Apr 11 '18

That package is required by default by Laravel Framework so it is already present.

jakebman • Apr 11 '18

My apologies, that is a valid uuid4 method. I implied that it wasn't a valid UUID generator, and I was wrong on that point.

I'd still recommend not writing it yourself, and using a tested library implementation, which would provide other variants of UUID like 1, 3, or 5 that have the uniqueness guarantee and are harder to write yourself.

They also make it easier to follow the recommendations in this thread about not using the string representation of a UUID, which takes up more than twice the space in your database.

Adam Cameron • Apr 11 '18

I second the sentiment about not using randomness as a proxy for uniqueness. In general it's probably not gonna be a problem doing it your way, but if yer writing a blog article about it... best to demonstrate the "right" way.

There's an RFC for UUIDs, which should be the first port of call when considering this stuff: tools.ietf.org/html/rfc4122 (warning... like with all RFCs, it's pretty dry reading ;-)

Another consideration is make sure you use a DB which actually stores the UUID as an integer (or has a specific UUID type, which will be an integer under the hood), if you want the DB to scale. String-based UUID values don't index so cleanly. For small (and possibly medium) loads, this is unlikely to be an issue, but should be a consideration.

One way to mitigate this is to still use just an auto-increment int as the PK for a table and in FKs, but for stored objects that need to be fetched via a public interface, use a UUID for that lookup (for the less-hackable URLs, as per your article).

jakebman • Apr 11 '18

I jumped down Kati's throat a little hastily - uuid4() is RFC compliant as far as I could skim. It sets the correct bits for a version 4 UUID, which generates the rest of the bits randomly. That's a valid UUID.

Robbert Müller • Apr 11 '18

when using mysql as reference; Substitute integer with binary(16) because a integer is just 4 bytes long, and a UUID needs 16 bytes

Adam Cameron • Apr 11 '18

Oh sure, sorry I was not clear. I was talking about the distinction between the concepts of integers vs strings in the general sense, not an implementation-specific one.

I figured the size require was a given, but probably should not have assumed.

I see MySQL does not have an integer type that can contain a UUID:
dev.mysql.com/doc/refman/5.7/en/in...

That said, how well will a binary column work as a PK and for FK relationships?

Robbert Müller • Apr 11 '18

Bad,

with innodb, the primary key is added to every indexrow.

so lets say we have the following table
|uuid|name(10)|password(10)|
with indexes:

primary key uuid, index row length 16
index name, index row length 16+10
index name,password, index row length 16+10+10

where we guarantee that uuid will stay the same for ever, and is used the user identification

id could change when we export/import the dataset in a new application or when we connect to an external application
where

Robbert Müller • Apr 11 '18

Storing a UUID as a string is very bad for your database performance,
see also:

There are packages for using uuid's as primary key, but i never used them

Jens • Apr 11 '18

Please don't use mt_rand for generating UUIDs. As the PHP documentation notes this function does not generate cryptographically secure values and you will end up with a lot of collisions.

Better use random_bytes which is crypthographically secure. Example:

function uuidv4()
    {
        return implode('-', [
            bin2hex(random_bytes(4)),
            bin2hex(random_bytes(2)),
            bin2hex(chr((ord(random_bytes(1)) & 0x0F) | 0x40)) . bin2hex(random_bytes(1)),
            bin2hex(chr((ord(random_bytes(1)) & 0x3F) | 0x80)) . bin2hex(random_bytes(1)),
            bin2hex(random_bytes(6))
        ]);
    }

Kindly taken from paragonie.com/b/JvICXzh_jhLyt4y3

Besides that as noted in the different comments use some library which is able to generate the uuids in binary form and store them also as binary in the database.