Re: dbdebunk 'Quote of Week' comment

"Roy Hann" <specially_at_processed.almost.meat> wrote
> "Frank_Hamersley" <terabite_at_isat.bigpond.com> wrote in message
> > I understand all the points and concerns they generate...but in my own
> > personal toolkit of techniques I have found I can use surrogate keys and
> > suffer none of the grief you attribute to them.
>
> I believe you are fooling yourself.

I'll concede from where you stand its a reasonable bet to place given the run rate of the "profession" and the fact you don't know me from Adam!

> > I guess I should declare 27 years of involvement with gadgets starting
in
> > the age of PDP-8/11's, Altairs, Alpha Micro, CDC Cybers (what a machine
that
> > was) might have taught me a few tricks in this regard. So all you pups
> > searching for gems should prolly accord 80 in an 80/20 measure of Joes
> > dissertation.
>
> I have been in this field just as long as you. (I still have a copy of
the
> MITS Altair newsletter with a Chirstmas photo of Bill Gates and the rest
of
> the Microsoft team--all 16 of them.)

Not autographed?

> In that time I have seen/written/endured untold mountains of spaghetti
code
> do to foolish and misguided things, that had I known and followed the
advice
> of people like Date and Pascal (and maybe even Celko on occasion) I could
> have mostly avoided.

Bad luck! I was fortunate to be educated by a prof who was a Pascal addict and insisted on showing us, via recursion amongst other things, how power could be achieved using elegant designs and coding. I have carried this mantra over the years and it has served me well. The other aspect I place great stead in is discipline - which IMO is an inherent trait, albeit reinforced by observations like yours. Most often these traits are not recognised by management it the search for quick thrills ;-)

> If you were to explain to me how unnecessary surrogate keys silently
conceal
> corruption, and how you guaranteed that they wouldn't, and that it all
ended
> up being cheaper, simpler, and more maintainable than if you hadn't used
> them, then I might be prepared to accept that you haven't suffered any of
> the grief. But since you haven't explained that, I'm more inclined to
think
> you just haven't noticed or recognized it. Not noticing that you have
> cancer is not the same as not having it.

If the surrogate keys were indeed "unnecessary " then you would have a valid point. In my current experimental work they are not (IMO at least) unnecessary.

When looking at the horror foisted on use by Access suggesting (nay almost insisting) on id columns as PK's I would further agree. Against my inclinations I have built a few small but reliable multi-user apps in Access over the years (even with id columns) but the cost of managing the risks you identify was quite traumatising when the product was marketed as Gods gift to "ease of use".

> It is not too late to explain now. I keep an open (but properly
sceptical) mind.

I knew this question would arise and I beg the readers tolerance for I haven't the time (right now) or inclination (as I am still moderately proprietal about the techniques) to lay it all out here before I have resolved a potential business opportunity. However I will say that I am not using more than 1 table with an identity attribute and in a similar vein to Ken's Andromeda I am not going to code it all by hand. As I said above the work is experimental at the moment but the key challenges still to be solved are not related to the use of surrogate keys.

Cheers, Frank. Received on Sat Aug 20 2005 - 09:45:43 CEST