Re: Natural keys vs Aritficial Keys
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 22 May 2009 17:23:10 -0300
Message-ID: <4a1709ae$0$23776$9a566e8b_at_news.aliant.net>
> <snip>
>
>
> I suspect I'd have to do a bit of revision to properly answer this, but
> the following quote from the blurb on SQLAlchemy's homepage suggests to
> me that it at least provides the means to avoid the first Blunder:
>
> "Map objects to not just tables but to any arbitrary join or select
> statement"
>
> Which is not to say that people won't Blunder when using it, but at
> least it doesn't force one to Blunder (which I suspect is all one can
> reasonably ask of an ORM).
Date: Fri, 22 May 2009 17:23:10 -0300
Message-ID: <4a1709ae$0$23776$9a566e8b_at_news.aliant.net>
Dave Hughes wrote:
>> Dave Hughes wrote: >>
> <snip>
>
>>> 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?
>
> I suspect I'd have to do a bit of revision to properly answer this, but
> the following quote from the blurb on SQLAlchemy's homepage suggests to
> me that it at least provides the means to avoid the first Blunder:
>
> "Map objects to not just tables but to any arbitrary join or select
> statement"
>
> Which is not to say that people won't Blunder when using it, but at
> least it doesn't force one to Blunder (which I suspect is all one can
> reasonably ask of an ORM).
Nope, that's still the first blunder: mapping object instances to tuples. Derived tuples are still tuples. Received on Fri May 22 2009 - 22:23:10 CEST