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