Re: Primary Key

On Nov 16, 2007 9:50 PM, Greg Smith <gsmith(at)gregsmith(dot)com> 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'...