Re: UUID column as pimrary key?

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: UUID column as pimrary key?
Date: 2011-01-06 20:39:34
Message-ID: 20110106153934.a655b5c2.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In response to Chris Browne <cbbrowne(at)acm(dot)org>:
>
> It seems to me that using serially assigned values, along with manually
> assigned server IDs, to construct a would-be-unique value, is likely to
> introduce quite a lot *more risk* of system failure than would the use
> of UUIDs.

First off, server IDs are not randomly assigned. They are assigned
automatically when the software is activated and tracked by the master
server.

Second, there is a very simple mechanism to prevent attempted "device
cloning" from causing a problem. (it's not a particularly difficult
problem to solve, actually)

Third, and very important, is the following conversation we had during
planning:
"Can we get good quality random data on mobile devices?"
"We'll have to research it, we don't know yet."
"Wait, before we do the research -- if we find that some mobile devices
have good quality random data and others don't -- can we tell the client
which devices they're allowed to use?"
"No, the client will dictate which devices it must work on."

So basically, we realized that even if our concerns about UUID
collisions we're unreasonably paranoid, we still couldn't guarantee
that the devices would be up to the task of generating UUIDs with
sufficient randomness.

As I tried to point out earlier in the thread, the collision issue was
one of MANY things we considered in this design. It is, however, the
ONLY one that's directly relevant to the original conversation. Now
that my description of our design seems to be coming under fire, I
feel the need to at least point out that we thought it through more
than that. I suppose that's mostly my own fault for trying to bring
in an example that it's impractical to discuss in full detail.

As other people have pointed out, there are concerns about malicious
impersonation, device failure, data corruption ... each of these may
be more or less likely or dangerous than UUID collision, but not all
of them are _intended_ to be solved by not using UUIDs, so claiming
that abandoning UUIDs does not fix these problems is completely
correct, and also a straw man.

> So someone that rules out UUIDs based on some fallacious imagined
> "infinite chance of collisions" is jumping away from a small risk, and
> accepting one much more likely to take lives.

The possibility of collisions is not fallacious, however, the use of
"infinite" (I don't remember who wrote that) is obviously not correct.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2011-01-06 21:08:27 Re: pg_dump and database size question
Previous Message Richard Huxton 2011-01-06 20:38:01 Re: Pl/perl and perl version-tip in doc