On 10/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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.
I absolutely agree with you here. Reporting is one of those areas for which doing more complex selects is key (possibly dropping down to raw DBAPI rather than SQLObject in order to just get the specific info required). > 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. In the case of Todd's example, thinking in objects seems like the way to go. In all things, you do need to tailor the approach to the application at hand. Kevin > > 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 > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
