Re: Natural keys vs Aritficial Keys
Date: Thu, 21 May 2009 11:40:24 +0200
Message-ID: <gv37i2$lmh$1_at_newsreader2.netcologne.de>
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.)
Yes, this is true with Rails out of the box, but there is an extension
available at
http://compositekeys.rubyforge.org/
that allows the use of composite keys. I haven't used it myself, yet, so
can't comment on how well it works.
> 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.
Here you appear to take a shortcut in the argument. Would you mind to
elaborate?
Lack of understanding on whose part? Are you sure you're not mistaking a
trade-off between ease of development, given the constraints of a
specific platform, and adherence to data modeling principles as lack of
understanding? I can be fully aware of doing something wrong, but do it
nevertheless when it is the less wrong of two wrong alternatives.
Michael
--
Michael Schuerig
mailto:michael_at_schuerig.de
http://www.schuerig.de/michael/
Received on Thu May 21 2009 - 11:40:24 CEST