Hi Ian
In a recent case modelling something similar to this we used the address as
a bean in its own right, with the primary key encapsulated in the person
data in an opaque fashion. This worked effectively as we are using a
PO database for the address with a corrections table in Oracle overlaid on
top of it. Addresses may then be keyed into by more than one person.
In this case, the tradeoff is based around the assumption that addresses are
mostly looked up for read-only access, in which case we can use optimistic
(timestamp) based coarse grained beans to copy the address data client side
for display, and assume that two operatives attempting to modify the same
address is very unlikely (so the timestamp overhead works). In addition to this,
a set of fine grained methods are provided on the entity bean for critical
updates.
This combination seems very effective.
Joel Crisp
Senior Java Architect, SUN PS Java Center (UK)
Ian McCallion wrote:
>
> Lennart Petersson wrote:
>
> > Hi Rickard! It would be ok to merge the two tables, but it is not correct
> > normalization since two or more person actually can have the same address.
> > Then if you merge the Resume and the Address table then you would have same
> > Address data in more then one place and everyone of us knows what that means
> > in maintenance...
> >
> > Rickard �berg wrote:
> >
> > > Interesting. One thing that I would change though is to merge the 1-1
> > > tables, i.e. put the columns in the Address table in the same table as
> > > Resume. Both Resume and Address could be CMP-mapped to the same table.
> > > Anyone see any problem with that? It would simplify things quite a bit
> > > IMHO.
>
> To see which is right you need to ask what you want updating an address to mean.
> If you want it to mean the postoffice has rewritten the rules about how to
> specify an address then addresses should be in a separate table. But if (as is
> more normal) you want it to mean that the person has moved, or the address was
> specified inaccurately, then it makes more sense to merge the tables as Rickard
> suggests.
>
> Ian McCallion
> CICS Business Unit
> IBM Hursley
> [EMAIL PROTECTED]
> Tel: ++44-1962-818065
> Fax: ++44-1962-818069
>
> ===========================================================================
> 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".
