Re: BIG Joins

>
> > I`m curious... how many people out there know of a runtime environment
> > where a "common" operation on a database involves a join of more than,
> > say, 5 tables?
> >
> > It seems to me this is fairly rare, limited mostly to large reports
> > that would get spooled off at EO[DWMY].
>

 Depends what you mean by 'runtime environment'.  

 I've written forms triggers using eight or nine tables, with maybe  a couple of look-ups thrown in. These came back in under ten seconds,  mainly due to a cunning hub-and-spoke database design.  

 I've just finished a query for a Financials10 report which necessitated  a twenty-five table join (in order to ORDER BY fields in different  subledgers). I wouldn't say it was greased lightning, but you don't  have to run it overnight. (Actually, we've yet to prove that this is  true in a high-subscriber business environment.)  

 As I have mentioned in previous threads in this group, small and simple  SQL is generally preferable, given a procedural tool to set it in - but,  I dunno, writing enormous bloody great statements is just much more  fun - and occasionally unavoidable.  

 However, big joins can be horribly confusing for subsequent programmers to  figure out, so I recommend generous helpings /* of in-code comment */,  especially for particularly-devious decodes, outer joins and so on.      

M

-- 
-----------------------------------------------------------------------------
                                                     MarkB_at_aboy.demon.co.uk
 Lyric Quiz of the Week: "You snatch a tune and you match a cigarette"