Re: Natural keys vs Aritficial Keys

"Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message news:Df6dnZMSF6ohZonXnZ2dnUVZ_gadnZ2d_at_earthlink.com...
> Walter Mitty wrote:
>> I'm confused about some recent trends in database design.
>>
>> When I learned databases, about a quarter of a century ago, the
>> preferred
>> practice was to use natural keys to refer to individual table rows,
>> unless
>> there's some real good reason to go with an artificial key. I've run
>> into a
>> few cases where I chose to use an artificial key, but most of the time
>> I've
>> used a natural key. [...]
>
> Somebody mentioned in an answer on StackOverflow that (Ruby on) Rails
> requires all tables to contain a column called 'id' (and, by
> implication, that column should be an 'identity' column or
> auto-generated value). (I've not verified that this is so.)
>
> I've also seen numerous suggestions that modern web-ish environments
> (Rails, etc) get confused by composite keys.
>
> In all cases, the problem seems to be a lack of understanding.
>
> --
> Jonathan Leffler

Thanks, Jonathan. This goes a long way towards clearing up my confusion. If the application development tools are biased towards auto-generated simple id columns, then it's only to be expected that people who drift into database design would adopt that practice, and think of it as a de facto standard.

So people who argue for modeling with natural keys, as I do, are out of step with the rest of the parade. Oh well. At least I know where the other opinion is coming from. And, at the end of the day, non trivial design problems generally have more than one acceptable solution. If people can get acceptable results with Rails out of the box, who am I to argue? Received on Thu May 21 2009 - 12:44:50 CEST