Re: Natural keys vs Aritficial Keys

From: Dave Hughes <>
Date: Thu, 21 May 2009 12:28:47 +0100
Message-ID: <>

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 :)


Dave. Received on Thu May 21 2009 - 13:28:47 CEST

Original text of this message