Re: Inefficient query plan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>I may be a little bit over-sensitive on the topic, because I've seen
>so many people who consider it "wrong" to use natural keys on any
>table *ever*.  About one out of every four or five programmers who
>gets hired here feels compelled to argue that we should add
>surrogate keys to all our tables for no reason beyond "it's the
>thing to do".  I've been at this for 38 years, most of that as a
>consultant to a wide variety of businesses, government agencies, and
>NPOs; and in my experience it usually is *not* the right thing to
>do.
> 
>Don't worry -- when I see evidence that surrogate keys will solve a
>problem which has not yielded to more conservative solutions, I'll
>suggest using them.
> 
>-Kevin
>

Ah feeel your pain, brother.  Been there, done that.  In almost every case, those who make the "thou shalt always, and only, use a surrogate key" cite folks like Ambler as authoritative rather than folks like Date.  The Kiddie Koder Krew are woefully uninformed about the history and development of RDBMS, and why some approaches are more intelligent than others.  Ambler, et al coders all, have poisoned more minds than can be counted.

Dijkstra called out BASIC and COBOL for polluting the minds of young coders.  Allowing Ambler and the like to be "thought leaders" in RDBMS is just as polluting.

There, I said.

-- Robert

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux