what happens when the OO model makes things too slow?

[sde]

i was trying to be pretty strict with my OO approach to the support app i'm developing.

the problem with that is TOO MANY QUERIES! for example, to show an issue history, you need to build the past 10 or so issues for a specific customer.

for each issue, you then need to build a customer object, which calls the phone and product files, and then build an employee object.

with each query costing me from 500-1200ms, this can really add up. i'm dealing with an ibm as/400 -> db2.

the work around i used is to just code a join query in the jsp page itself. this makes things soooo much faster. i only do this when a list of objects need to be viewed which normally would have to execute multiple queries for each row.

what would you do?

[Belisarius]

It sounds like you need some more specialized queries. I'm not fully familar with what you're doing, but it sounds like you built queries into the datastructure, whereas I tend to keep queries out of the datastructure. I have utility classes build the datastructure I need. For instance, should I want to perform a specific task (such as get an issue history), I'd write a method getIssueHistory(), pass it all the variables I'd need, and form the whole query right there, if possible.

[technobard]

Sorry for the late reply. I've been on vacation in sunny San Diego. Ahhh...Er, where was I? Oh, yeah. Just a couple of comments to build on Belisarius' statement. It sounds like you're equating a normalized database structure with object orientation. A customer object, for example, should contain all of the info that makes sense for a customer. This may or may not match up with a normalized database structure. Objects can have embedded one to many relationships like multiple addresses or phone numbers. Relational databases can't. When you map the objects to the database, that mapping can very often be a join between multiple tables. You may also have cases where you plan on processing some resultset, but never actually instantiating the values as objects. Specialty getter methods that either take parameters or contain complete embedded SQL (not my favorite) are perfect for this sort of thing. I'm sure by now you've moved past this issue, but I wanted to add my 2 cents, for what it's worth.

[sde]

thanks for the response guys and you're both pretty much right on.

my solution was as i originally started to do, .. just joining tables in areas that i need to display a list of joined data.

it's not pretty, but it's what i gotta do to make it work right.