When the table involved is limited, it is ok to have a few level(I would say no more than 3) for loops. Beyond that, SQL is much better, even though a bit hard to understand initially.
Then there is the performance issue. Retrieving everything and process at the client is just impossible. I should revise it and say that for transactional based things, think in object may be ok(sometimes desirable too) but once we get into reporting or playing around with large amount of existing data involving lots of tables, SQL is designed for it. Of course, it really depends on the kind of apps. I am just feeling uncomfortable seeing simple advice of "don't think SQL, think object" as it really depends. Kevin Dangoor wrote: > On 10/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > I beg to differ. Think in objects is in general a step backward except > > for the very simple CRUD stuff. > > How so? > > Kevin
