Re: vehicle to autoparts relationships
From: Volker Hetzer <firstname.lastname_at_ieee.org>
Date: Thu, 07 Dec 2006 18:49:08 +0100
Message-ID: <el9k6j$k3p$1_at_nntp.fujitsu-siemens.com>
>
> And the third alternative is to use sets (where atomic parts are
> elements, and the part assemblies are sets). No recursion is needed
> then! The ancestor chain query is a relational division, but in a
> typical autoparts shop application, why would one like to know what
> chain of assemblies includes an atomic part?
fiddly bits found in junk box -> valve
lead, clamp -> weight
valve, tyre, rim, weights -> wheel
wheels, lots of other stuff -> car
So, i'd prefer the recursion. That gives more flexibility with respect to the level of detail.
Date: Thu, 07 Dec 2006 18:49:08 +0100
Message-ID: <el9k6j$k3p$1_at_nntp.fujitsu-siemens.com>
Aloha Kakuikanu schrieb:
> Neo wrote:
>> At extremes, there are two type of solutions to your problem in RMDBs. >> One solutions ends up with many specialized tables. The other solution >> ends up with fewer generalized tables with recursive joins. Each has >> advantages and disadvantages. You will have to find the right balance >> for your specific requirements.
>
> And the third alternative is to use sets (where atomic parts are
> elements, and the part assemblies are sets). No recursion is needed
> then! The ancestor chain query is a relational division, but in a
> typical autoparts shop application, why would one like to know what
> chain of assemblies includes an atomic part?
fiddly bits found in junk box -> valve
lead, clamp -> weight
valve, tyre, rim, weights -> wheel
wheels, lots of other stuff -> car
So, i'd prefer the recursion. That gives more flexibility with respect to the level of detail.
Lots of Greetings!
Volker
-- For email replies, please substitute the obvious.Received on Thu Dec 07 2006 - 18:49:08 CET