From: Josh Berkus <josh@agliodbs.com>
To: mark@mark.mielke.cc
Cc: Bob Ippolito <bob@redivi.com>
Cc: jonah.harris@gmail.com, pgsql-hackers@postgresql.org, nathan wagner <nw@hydaspes.if.org>
Subject: Re: uuid type for postgres
Date: Tue, 6 Sep 2005 18:40:27 -0700
Message-ID: <200509061840.28068.josh@agliodbs.com> (raw)
In-Reply-To: <20050907011135.GA7369@mark.mielke.cc>
References: <20050906135057.GA24136@granicus.if.org>
<200509061802.51089.josh@agliodbs.com>
<20050907011135.GA7369@mark.mielke.cc>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: josh@agliodbs.com, mark@mark.mielke.cc, bob@redivi.com, nw@hydaspes.if.org
Subject: Re: uuid type for postgres
In-Reply-To: <200509061840.28068.josh@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox