Date: Tue, 6 Sep 2005 21:11:35 -0400
From: mark@mark.mielke.cc
To: Josh Berkus <josh@agliodbs.com>
Cc: Bob Ippolito <bob@redivi.com>, jonah.harris@gmail.com,
	pgsql-hackers@postgresql.org, nathan wagner <nw@hydaspes.if.org>
Subject: Re: uuid type for postgres
Message-ID: <20050907011135.GA7369@mark.mielke.cc>
References: <20050906135057.GA24136@granicus.if.org>
	<36e6829205090612575b954f38@mail.gmail.com>
	<3F60E55D-B558-4929-B614-C230EACFF473@redivi.com>
	<200509061802.51089.josh@agliodbs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200509061802.51089.josh@agliodbs.com>
User-Agent: Mutt/1.4.2.1i

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 bind them...

                           http://mark.mielke.cc/