Re: Natural keys vs Aritficial Keys
From: Dave Hughes <dave_at_waveform.plus.com>
Date: Thu, 21 May 2009 12:28:47 +0100
Message-ID: <UsCdnb7eM9t4p4jXnZ2dnUVZ8imdnZ2d_at_brightview.co.uk>
>
> 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.
Date: Thu, 21 May 2009 12:28:47 +0100
Message-ID: <UsCdnb7eM9t4p4jXnZ2dnUVZ8imdnZ2d_at_brightview.co.uk>
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 :)
Cheers,
Dave. Received on Thu May 21 2009 - 13:28:47 CEST