From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | mark(at)mark(dot)mielke(dot)cc |
Cc: | Bob Ippolito <bob(at)redivi(dot)com>, jonah(dot)harris(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, nathan wagner <nw(at)hydaspes(dot)if(dot)org> |
Subject: | Re: uuid type for postgres |
Date: | 2005-09-07 01:40:27 |
Message-ID: | 200509061840.28068.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2005-09-07 01:47:06 | Re: uuid type for postgres |
Previous Message | Bob Ippolito | 2005-09-07 01:15:21 | Re: uuid type for postgres |
From | Date | Subject | |
---|---|---|---|
Next Message | nathan wagner | 2005-09-07 02:36:06 | Re: uuid type for postgres |
Previous Message | Bob Ippolito | 2005-09-07 01:15:21 | Re: uuid type for postgres |