What is this unique ID called?

I’m seeing lots of code using unique ids in the format 882efd58-4906-4610-a9b0-dcc5ac9bb1c2

What’s this format called and how can I easy generate it using php?

Is it best practice to use it or can I just generate my own?
Any disadvantage to using this format?
Stephen ForlanceAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Julian HansenCommented:
That's called a GUID (Globally Unique Identifier) or UUID (Universally Unique Identifier).
It is a char field 36 chars long made up of hexidecimal values in a 8:4:4:4:12 configuration.

The value is guaranteed to be unique. It is calculated using a variety of factors.

For the purposes of data storage it is often used as a unique ID on rows in a table. There are both advantages and disadvantages to using it over a normal Autonumber

- because it is guaranteed unique - if you have to merge records from multiple sources you don't get a key collision
- It is unguessable - with Autonumbers if you see a url ...?id=23 then you can guess that there must / might be a 22/21/24 etc and by guessing the id you can get access to other data - this has happened a number of times in some high profile hacks.
NB: UUID's are not always unguessable - if you know enough about where and how they were generated. For the purposes discussed above though they are sufficiently unguessable for most purposes.

-  They take up a lot more space - when your database grows large - and if your record is related to one or more other tables this could become a factor
- They don't index well - sequential values are always going to require less space and will be faster when searching indexes.

You should use them only when necessary - they shouldn't be a default implementation.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Julian HansenCommented:
To your question on how to generate it. There are PHP scripts to do this for you. If you are going to be using it in a database (MySQL) then you can use the database to generate it for you. MySQL has the UUID() function that will generate a UUID - you can use it in queries or you can call a query

Open in new window

To get a UUID from the DB
Just to be clear, it's not really "guaranteed to be unique" but it is mathematically improbable that you would ever have a collision.

I fully agree that they should NOT be a default implementation, especially for database keys. Your best bet for usage with them in databases is when dealing with a multi-node database setup where many servers could be generating data that is all synced up within the same table. If you use auto-incrementing key values, you have to deal with different offsets and increments in order to avoid key collisions (and it's difficult to maintain if the number of servers grows). But if you have 8 database servers all within a cluster and cannot rely on them being all connected at once, GUIDs are an easy way to deal with the data sync.

But for most projects out there, databases are relatively small or kept on one server (possibly 2), so the typical auto-incrementing ID works well for those situations, and it's usually a better starting point. You can always convert to GUIDs later.
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

Julian HansenCommented:
Just to be clear, it's not really "guaranteed to be unique" but it is mathematically improbable that you would ever have a collision.
for there to be a one in a billion chance of duplication, 103 trillion version 4 UUIDs must be generated.

One option is to convert the UUID back into a number by removing the dashes and then converting the hex digits back to a number.

Store this instead and you can then gain the benefits of faster indexing and lower footprint in the db.
Stephen ForlanceAuthor Commented:
But wouldn't that increase the chances of a collision, effectively reducing the uniqueness?
Stephen ForlanceAuthor Commented:
Currently Im using sha1(time()) to create a unique ID, what do people think? Also included in the creation process is a look up to see if the ID is already being used in the db table (uniqueness is per table).
Stephen ForlanceAuthor Commented:
As also thinking of salting it (both ends)
Julian HansenCommented:
But wouldn't that increase the chances of a collision, effectively reducing the uniqueness?
A hex number of 16 digits expressed as a string or a number is the same - you can't have two hexadecimal strings that differ that map to the same number.

A hash has (I believe) more chance of a collision - hashing is usually used for obscuring rather than uniqueness - as is salting.

What is the use case here?
Stephen ForlanceAuthor Commented:
Use case is to create a unique ID for a db record, which is used to access the record (along with other data), should not be guessable, or sequential. But it will also appear in URLS, for example record.php?id=eflkmrl4krj4lkjewjfklwej
One option is to convert the UUID back into a number by removing the dashes and then converting the hex digits back to a number.

Not sure what you're thinking here. The hex values aren't encoded digits so I'm assuming you are thinking about just converting from base-16 to base-10, but that would result in a number so large that it wouldn't fit in even the largest numeric data type in a database. You'd have to store it in multiple fields, at which point the raw UUID would be faster.
Don't use a salted sha1(time()) hash. A SHA-1 hash will give you 40 characters and salting it will make it even larger. A UUID is 36 characters and has a far better chance at being unique.
Julian HansenCommented:
Not sure what you're thinking here.
Store as BINARY(16) refer https://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/
Interesting. Would never have thought of that. It's a little clunky to use since you would need the overhead of converting between formats when you wanted to use the value outside of MySQL but it would definitely perform better in an index.
Stephen ForlanceAuthor Commented:
That's a very interesting approach, what's the functions to convert between binary?
Julian HansenCommented:
Not sure what the question is?
Stephen ForlanceAuthor Commented:
How would I convert the UUID to binary, and back again? I was interested because of the comment regarding the indexes being faster
Julian HansenCommented:
The process is contained in the link I posted.
Stephen ForlanceAuthor Commented:
The index speed increase is interesting, Ive never used Binary, because always thought it as not really applicable to web apps. Very interesting!
Make sure you consider the conversion overhead outside of the index, too. If the indexing speed is marginally faster but still requires the client to work in the UUID format, you might cause more confusion down the line (one more thing requires explanation to someone else) and make it harder to perform adhoc management of the data. So test the difference in performance (with the NO CACHE option) and consider volumes before committing.

In other words, don't spend $250,000 dollars on a sports car if you're only ever going to drive one mile, when a $15,000 budget car will get there in just about the same time. Sometimes simplicity can be worth a tiny bit of lower efficiency, but it all depends on your circumstances.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.