Umm..
It seems you're suggesting doing a table join in code.
I've always thought this practice somewhat dangerous - you're essentially
competng with programs like Oracle which specialise in doing this.
May work for a simple join on two tables, but what about 3 or 4 ?
Al Fogleson wrote:
> Nothing says that the address has to be an EJB. :)
>
> You could make the address a class and have it grab all the addresses from
> the database, then in the customer bean you can match the address with the
> customer using the PK and FK relationship. if you further implement the
> address class as a singleton it can retain the result set over multiple
> instances of the Entity bean. In your case I would likely use a
> findAllCustomers, and spit that back to the rendering engine to put on the
> web page. makes for 2 database calls, one to get all the customers, and one
> to fill the address class.
>
> Al
>
> ----- Original Message -----
> From: Tim Fox <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 18, 2000 11:17 AM
> Subject: Object-relational problem
>
> Here's a problem I've been chewing over for a while now and haven't come
> up with a satisfactory solution.
> It's one of the classic object-relational problems.
>
> Here's a simplified description (please note that this is a fictitious
> example - I've simplified it for clarity)
>
> I have 2 ejbs: a Customer and an Address.
> The customer has a home address.
>
> I'm displaying a list of all customers satisfying certain criteria along
> with their home address on a web-page.
>
> There would be one customer & address per line.
>
> This would look something like:
>
> Customer Name Customer Address
> =========== =============
> Joe Bloggs 1 High Street, Newtown
> John Doe 23 Synchronicity drive, London
> Jane Doe 2 Big Street, Badville
>
> Now the page is hit a lot so I want to get the entire list using one
> query - this is pretty easy in SQL - a simple join across the customer
> and address tables.
>
> The last thing I want to do is query for all the customers, then, for
> each customer query for the address - this would cripple the system
> since I'd have a new query for each row of the page.
>
> However, if I'm using ejb then it seems I could either:
> 1.
> Use a finder method to get the list of customers given the criteria,
> then...
> For each customer in the list, use the findByPrimaryKey() (or whatever)
> method to find the address.
> This is probably the worst solution since it would probably involve a db
> query for each customer address.
>
> 2.
> Use a finder method to get the list of customers given the criteria,
> then...
> Use a finder method to get the list of addresses given the criteria.
> This basically involves running the same (or very similar) query twice -
> once in the Customer finder method, and once in the Address finder
> method.
> This, although better than 1) seems very wasteful
>
> 3.
> Do the query once, and pass the resultset into the finder methods of the
> customer and address objects - don't know if this is possible though due
> to remote calls and marshalling of the resultset
>
> 4. Create a denormalised ejb called AddressCustomer which is an
> amalgamation of the Address and Customer objects. Yuck!!!
> Then I also end up with an AccountCustomer, AccountCustomerStatement,
> ProductManufacturerSupplier etc. ad infinitum objects.
> Basically the nice OO model gets shot to f*** !!
>
> I'd been interested in any comments/solutions people have implemented,
> as this is really bugging me
>
> (BTW if I wasn't using ejb I'd use 3) since I wouldn't have any remote
> calls problems).
>
> Cheers
>
> --
> Tim Fox (��o)
>
> Senior developer
> Hyperlink plc
> http://hyperlink.com
>
> email: [EMAIL PROTECTED]
> phone: +44 (0) 207 240 8121
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
Tim Fox (��o)
Senior developer
Hyperlink plc
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
