Re: uuid type for postgres

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