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.