Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!shelby!portia.stanford.edu!chesky
From: chesky@portia.Stanford.EDU (Snehylata Gupta)
Newsgroups: comp.databases
Subject: Re: Join Contest
Message-ID: <1990Jul24.204233.20766@portia.Stanford.EDU>
Date: 24 Jul 90 20:42:33 GMT
References: <5265@plains.UUCP> <933@dgis.dtic.dla.mil> <8619@cognos.UUCP>
Organization: AIR, Stanford University
Lines: 35

In article <8619@cognos.UUCP> nigelc@cognos.UUCP (Nigel Campbell) writes:
>>gus@plains.NoDak.edu writes:
>>
>>>Recently I heard that an IBM-type db person claimed that it's
>>>not uncommon in commercial db applications to join as many as
>>>10-15 (maybe even 30) tables in a single query.
>>
>
>>It is uncommon. 
>
>	really ..... 
>
>>Ask your IBM-type db person to substantiate
>>his claim.  "Extraordinary claims require extraordinary
>>justification".  In fact it's difficult to design a query that
>>makes sense with more than about five joins.

Once I had come up with a design which required a query where there waws
a 26 way join. It was very well normalized. How it would perform I do
not know because the tool was INGRES and INGRES has a limit of 30 tables
in your query. It was an unusual case I suppose. But it was the best
design then. It would have been interesting to see the query execution
plan. However I routinely use 8 way joins. 
This is also because INGRES likes thin tables more than wide ones.

In that project I had do denormalize it and work with a 4 way join.
(if I remember correctly).

If you insist I can give the design. But the logic is rather long
and I don't type at 80 wpm :-).  However if there is enough interest
then I shall ...

Thanks

Sanjay