Re: Natural keys vs Aritficial Keys

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 21 May 2009 11:09:48 -0300
Message-ID: <4a15607e$0$23750$9a566e8b_at_news.aliant.net>


Dave Hughes wrote:

> Jonathan Leffler wrote:
>

>> 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.

>
> Yes - Django's default ORM also defaults to auto-generated surrogate
> keys for everything (it can handle non-auto-generated keys, but only
> with a single column). However, many of the Python based web
> environments are now moving to the rather impressive SQLAlchemy ORM
> which handles "natural" keys just fine (including composites). I think
> I'm right in saying Pylons and Turbogears already default to SQLAlchemy.
> So, it's not all doom and gloom for those who prefer natural keys :)

But how many "Great Blunders" does the SQLAlchemy ORM make? Received on Thu May 21 2009 - 16:09:48 CEST

Original text of this message