>> but if it's poorly written and doesn't make use of client-server best practices then traffic could be as high as native tables.
>
>Hmmm... I can't think of a scenario where this is true. IASM data network data access requires access to the raw table and processing queries by having to pull query data local **in addition** to producing the query result set is inevitably going to have higher bandwidth usage than just pulling C/S resultset over the wire.
>
True when filters on the server reduce the amount of data sent over the wire - and inner joins are just another form of "where", as some heavy hitters in DB space were reluctant to offer "JOIN" syntax ;-)

In theory, whenever you denormalize via inner join the result set can be large the the sum of sizes or source tables - think reporting with cursor of all customers with their adresses when all bought something (first year of biz) and repeat buys happen often..

Whenever you need nearly unfiltered outer joins and execute them server side, chances are the result set sent over the wire is larger than the tables it was generated from - and Left Joins do turn up in biz settings. Full Join could be oodles worse, but I confess I cannot remember last time I needed one, so that would be straw man argument / just for the sake of making a point ;-)

regards
thomas