Re: uuid type for postgres

On Tue, Sep 06, 2005 at 06:02:50PM -0700, Josh Berkus wrote:
> However, Mark went on to suggest that we should recommend UUID over SERIAL
> in the docs, and that we could consider dropping SERIAL entirely in favor
> of UUID:
> ---quoth Mark------------------
> I suggest that UUID be recommended in place of SERIAL for certain
> classes of applications, and that it therefore belongs in the core.
> UUID and SERIAL can be used together (although, once you have a  
> UUID, it may not be useful to also have a SERIAL).
> ---------------------------------
> This was what I objected to; I believe that the use-case for UUIDs is
> actually quite narrow and assert that it's a very bad idea to promote them
> to most users.

Ahhh... :-)

I intended the word 'certain' to be emphasized in some way, rather
than dropped. There are genuine uses for UUIDs. I didn't intend for
everybody to pull out their database definitions and change them all to
use UUID instead of SERIAL.

Although - I don't think really bad things would happen if people did.
They would simply be making a non-optimal choice (abusing the type?).
Certainly nothing they weren't capable of before this particular
capability were to arrive. :-)

> I have a "problem" with SERIAL abuse, too. In general, new DB designers
> have come to increasingly believe that surrogate keys (SERIALs, UUIDs,
> hash ids etc.) are an intrinsic part of the relational model and a
> requirement for all tables. Terrible database designs have resulted,
> chock full of tables which lack real keys and cannot be normalized.

> UUIDs tend to encourage this sort of behavior even more than SERIALs, not
> because of any intrinsic quality in the data type, but because much of the
> literature on the subject treats them like some kind of "universal object
> identifier" and not distinguishing servers, relations, or real keys.

> To repeat, though, this isn't a reason to keep them out of core, but it
> *is* a reason not to throw them at newbies as the holy grail of row
> identifiers.

I agree. Although I lost it on the "cannot be normalized". I'm assuming
there are designs you have seen much worse than the ones I have seen. :-)

> For my part, I generally push implementing the UUID concept in a better way
> that keeps server, table, and surrogate keys atomic (and thus more useful
> and easier to debug).

My eyes are glazing over a bit on this last one. Atomic?

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/