Re: UUID column as pimrary key?

On Wed, Jan 05, 2011 at 07:46:18PM -0700, Scott Ribe wrote:
> And if somebody clones the disk to a new machine, but leaves the old one in service? Or do you use the MAC address and hope that's unique?
>

Excellent questions, and exactly the sort (as I was arguing elsewhere
in this thread) one has to answer in order to decide what the right
strategy is.

For instance, it may be that your application need is dealing with
incredibly valuable identifiers, that not cloning the disk is a matter
of national security, that the cost of finding and fixing a failed
unique identification case runs into the billions of dollars (not to
mention the millions of deaths), and that the assignment is performed
in real time by distributed systems that only eventually, if at all,
deliver data to a unified system. In this case, the cost of the
failure of uniqueness is very high, and it would be prudent to arrange
something that guaranteed that no assigner node could possibly create
a duplicate identifier. There are UUID approaches that can do this;
they mostly work by guaranteeing a fixed and assignable local part.
UUID vs. serial for one of those columns seems to me to be nothing but
an application efficiency problem.

What is far more likely is that ordinary-value identifiers are being
generated, and that you are using them for more or less pedestrian
reasons. The cost of an undetected duplicate is still maybe millions
of dollars, but the chances of a duplicate going undetected at
creation time (like, say, the MAC address of the creating machine is
used, the useful lifetime of the UUID is on the order of single-digit
years, and there are no more than 10 database back ends involved) are
fairly low. In this case, using a proven UUID generator seems like a
no-brainer to me (and in fact, I work on an application where we do
this).

I don't understand the number of knees in this conversation that seem
to be jerking against the answer, "It depends." Of course it depends.
If there were one answer for everything, developing good
database-backed systems wouldn't be something people would pay any of
us for.

A

--
Andrew Sullivan
ajs(at)crankycanuck(dot)ca