On Nov 16, 2007 9:50 PM, Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > On Fri, 16 Nov 2007, Merlin Moncure wrote: > > the sad fact is that sequences have made developers lazy > > Nah, developers were lazy long before that. If you ask Larry Wall it's a > virtue. well, 'lazy' in the sense that it encourages easy to solutions to difficult problems is arguably virtuous. intellectual laziness (which i most certainly am not accusing you [or the OP] of) is another matter. long years of wrestling with you and many other less talented individuals on this particular topic has imparted to me a little bit of weariness as well. furthermore, i have myself surrogated a database to victory on various occasions, although usually for performance reasons...so i'm hardly a zealot. i do however think that being able to separate data into tables using unambiguous keys lifted directly from the data is a critical skill. > I gave up on this argument ten years ago after a long battle with > well-known natural key zealot Joe Celko wore me out. He published one of > his many articles making a case for them using an example from the > automotive industry. Only problem was, the unique identifier he suggested > wasn't. At the auto parts company I worked for, I had just spent many > monotonous days contorting keys to work around a problem caused by the > original designer there, who misunderstood some nuances of how the "Big > Three" auto manufacturers assigned part numbers the same way Celko did. well, nobody's perfect... > He doesn't use that example anymore but still misses the point I tried to > make. The ability of the world to invalidate the assumptions that go into > natural key assignment are really impressive. I particularly enjoy that > so many systems are built presuming that the Social Security number for a > person is involatile that this topic comes up in their FAQ about identify > theft: http://www.socialsecurity.gov/pubs/10064.html that just means that the SSN is only part of the key that unambiguously defines a person, should that be a requirement :) database design, like many engineering disciplines, is a series of trade-offs mixed in with a couple of helpings of artistry and the few bits of theory that the sql standards committee was was not able to snuff out. like i said in my opening remarks, the issues at play are nuanced without clear cut answers. merlin p.s. no compilation of 80's albums is complete without 'full moon fever'... ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
