+1. Join the tables in a query and write an algorithm to parse the results into the view you need. One connection, one query, let the database do the work. Not very OO, but very efficient.
robert > -----Original Message----- > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Sent: Friday, March 12, 2004 3:37 PM > To: Struts Users Mailing List > Subject: RE: [OT] Object Design Question > > > It's always on a case by case basis. When and how much do you need at a > given time? Hibernate/JDO/OJB/etc can handle these things for you via a > config to specify lazy relationships. > > When you are talking about web application with read data (data purely > pushed to the view like a list of persons with addresses), then the best way > IMHO is to write a special view object and query for this case. > > List View Objects > Select By Id > Grab Business Object By Id > > > > -----Original Message----- > From: Avinash Gangadharan [mailto:[EMAIL PROTECTED] > Sent: Friday, March 12, 2004 2:26 PM > To: '[EMAIL PROTECTED]' > Subject: [OT] Object Design Question > > People, > I have a design question. It is regarding the retrieval of parent and > child objects in the best possible manner. For eg. Let's say there is a > Person object with properties such as ssn, lastName and firstname. It also > has a list child objects ( "Address" ) of addresses and a list of previous > employees ( "Employee" ). The Person, Address and Employee objects are > separate tables in the DB linked thru ssn. > > Now what do you guys think is the most efficient way of retrieving a > complete Person. > > The simplest way is ofcourse issue 3 queries one for person, other for the > list of address and the third for previous employees. But this does not > scale well with increasing size of the table data. For 100 rows of Person > 201 queries are issued. 1 which gets 100 persons, 100 each for there > subequent address and previous employees. Similarly for a 1000, 2001 > queries. > > Complex queries may be a solution which relies on filtering the resultset > but is there a more simple and intelligent approach. > > Is there a problem with the inherent design itself or is this a common > problem. > > Thanks and Regards > Avinash > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
