Substitute for MySQL's UUID Version 1 function?

Question

Context

Web application, PHP 5, MySQL 5.0.91

The Problem

I recently switched from using an auto-incremented integer

Answer 1

It's actually a fairly good idea to appreciate having the "similar parts". It will allow you to leverage the MAC address to be able to identify "which of my servers generated this UUID?"... which will be extremely helpful when migrating data between remote locations. You can even do "this is my test data" and "this is my production data" this way.

PHP has a large number of UUID-generator libraries.

Here's one PECL/PEAR thing (I never used it):

http://pecl.php.net/package/uuid

From the CakePHP framework:

http://api.cakephp.org/class/string#method-Stringuuid (cake 2.x) http://api13.cakephp.org/class/string#method-Stringuuid (cake 1.3)

Last generator option:

Consider using a Linux command-line uuid program, which would have the -v version control flag and related options, and using that to feed your database. It's sort of inefficient, but at least you won't have to write up your own generator functions.

http://linux.die.net/man/1/uuid - man page

(package uuid for Debian)

I noticed that for the namespace versions, you'll be generating lots of "long human names" to convert into uuids. As long as you don't have conflicts with those, it might be very sweet. For example, users registering with e-mail addresses... Get v5 uuid for that e-mail address... you'll always find that person! It seems to spit out the same UUID each time, and the UUID will represent the unique relationship bob@bob.com has with example.com, as a member.

uuid -v5 ns:URL "http://example.com/member/bob@bob.com/"

Commentary:

Also, UUIDs, the way you seem to be storing them, are CHAR(36)? You might regret that once comparison operators kick in.

Postgres will treat UUID as 128-bit values (and presumably do optimized binary operations), whereas MYSQL's CHAR(36) solution is looking at 36 bytes = 288-bits ANSI or 576-bits UTF8 plus-or-minus bits/bytes for office-keeping (and presumably do much slower multibyte-char-by-multibyte-char string routines).

I've actually put a lot of consideration into the issues for MySQL plus UUID... and my conclusion was that you'd want to write up a stored function that converts the hex representation into the binary representation for storage, and that would make all "select" statements require a conversion back into hex representation... and who knows how efficient any of that will be... so finally just switch to Postgres. XD

If you do want to switch to Postgres, try be very careful about installing it on your existing server(s) if they are production servers. As in... make a clone to test the migration process before actually doing a migration. I somehow managed to kill my system because of "installing this package will remove a large number of important other packages" (I don't know how the installer made those decisions).

Alternatively, go with Microsoft SQL for their GUID equivalent, if you're prepared to eventually pay them lots of money to operate a DB...

Doing UUID and MySQL just tends to be a bad idea at the moment.