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@mielke.cc / markm@ncf.ca / markm@nortel.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
bindthem...
 
                          http://mark.mielke.cc/