The schema is *not* normalized, you are correct. I did this because I
thought it would give me some advantages if I wanted to model my two objects
both as Entity beans.
I'm going to try and model the Fund as an Entity bean first, and just see
what issues creep in. It certainly will not be a common implementation, but
since none of the summary fields are updateable in this object, I don't
believe it is actually an incorrect implementation.
jim
----- Original Message -----
From: punit malik <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 13, 1999 11:04 AM
Subject: Re: Summary Beans?
> Hi!,
>
> >Fund as a Stateless Session Bean
> >================================
> >This is the way I am leaning right now. The user would request the AppAmt
> >for a Fund, and a database query would result in the correct summary
> >information. It just seems kludgy to me, since the table is not
normalized
> >at the fund level, and a change to description would result in a multiple
> >row update.
>
> I think its the best choice as your fund is a logical object. But if i am
> right **your fund_detail is not normalized and not your fund**.
> So if you can normalize your fund table then it may solve some of your
> performance hits. Like
> Table1:
> id description
> Table 2:
> id amt.
>
> Another advantage of doing this way is it gives you flexibility in
changing
> your schema for this logical object, fund, without doing anything in dbms.
> Disadvantage: Anytime you make change in fund_detail schema, you may have
to
> change your component.
> So it really depends on how stable is going to be fund_detail and fun
> schema.
>
> What do you say?
> Punit
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
>
===========================================================================
> 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".
