RE: J2EE Question

I agree with Jared. Usually you want to hold objects in some form of hash, where you can quickly grab the correct object by the key; a multi-column key is kinda hard to use for this.

I worked at a company that held _all_ objects in the same hash; therefore the requirement was to force every record in every table to have a unique key. Oy, don't do that...

> -----Original Message-----
> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> Sent: Thursday, April 24, 2003 9:57 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: J2EE Question
>
>
> I've done this a few times.
>
> The reason that I've had for doing it is that the associative
> table had children of it's own, and I don't like to propogate
> natural keys.
>
> Seems like a reasonable request.
>
> Jared
>
>
>
>
>
>
> DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
> Sent by: root_at_fatcity.com
> 04/24/2003 07:06 AM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> cc:
> Subject: J2EE Question
>
>
> We are in the process of creating some significant new
> schemas. Everything is being normalized, by the book. Now the
> Java developers are saying that
> on
> the associative entities, where many-to-many relationships
> are resolved by an extra table, they want an artificial key
> to be added. Normally these tables have two keys, one from
> each parent table. But the developers want
> an
> additional sequential key added to help them track this
> entity. They say
> it
> makes it easier to keep track of this object in the EJBs. Has
> anyone encountered this situation? Not being familiar with
> J2EE, I haven't a clue whether this is a reasonable request.
>
> Dennis Williams
> DBA, 40%OCP, 100% DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> and in the message BODY, include a line containing: UNSUB
> ORACLE-L (or the name of mailing list you want to be removed
> from). You may also send the HELP command for other
> information (like subscribing).
>
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author:
> INET: Jared.Still_at_radisys.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> and in the message BODY, include a line containing: UNSUB
> ORACLE-L (or the name of mailing list you want to be removed
> from). You may also send the HELP command for other
> information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jeremy Pulcifer
  INET: Jeremy.Pulcifer_at_kadiri.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).