> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Josh Berkus
> Sent: Tuesday, September 06, 2005 6:40 PM
> To: mark@mark.mielke.cc
> Cc: Bob Ippolito; jonah.harris@gmail.com;
pgsql-hackers@postgresql.org;
> nathan wagner
> Subject: Re: [HACKERS] 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.
What if you don't want to move anything from one system to another, but
you would like to do joins across many servers on a network?
It happens all the time. If you have a built in primary key for related
tables and they are guaranteed unique, then you have a leg up.
It is not unusual for the same schema to be used in many different
regional offices, but to have site specific data in each area.
