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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
