From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: mark@mark.mielke.cc
Subject: Re: uuid type for postgres
Date: Tue, 6 Sep 2005 18:40:27 -0700
User-Agent: KMail/1.8
Cc: Bob Ippolito <bob@redivi.com>, jonah.harris@gmail.com,
	pgsql-hackers@postgresql.org, nathan wagner <nw@hydaspes.if.org>
References: <20050906135057.GA24136@granicus.if.org>
	<200509061802.51089.josh@agliodbs.com>
	<20050907011135.GA7369@mark.mielke.cc>
In-Reply-To: <20050907011135.GA7369@mark.mielke.cc>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200509061840.28068.josh@agliodbs.com>

Mark,

> 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.
> :-)

Mostly it's the problem of tables that don't have a real key, only a 
surrogate key.  How do you know what's a duplicate?

> > 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?

Sure.  What's a UUID, after all?   It's three pieces of information:
1) A server or database instance identifier
2) A table identifier
3) A row identifier

e.g.:
chayote.sf.agliodbs.com | public.customers | 4271

Generally, it's pretty easy to just grab these 3 pieces of information 
separately and pass them with the data when you want to transmit between 
servers.  If there are space/overhead considerations, you can put them 
into a reversable hash.  I've never understood the complex measures which 
application developers take to create "universal" IDs.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco