I don't know if this is a "better" model at all. In fact, all this accomplishes is leaving behind tons of useless records. I'd only recommend this model if (for any reason) the "trail" of the truck history for this cargo.
This way of "marking" records also leaves you open for the obvious future problem of inconsistent handling of records. Where some programmers don't know about this "deleted" flag and just go ahead and update the records directly as you normally would. Lets go back to the original question. Why does doing a simple foreign key update coause "contention?" If you have an index on your FK column in the child table, the update on the child table can use the index to find the PK record quickly, and the update goes on as planned. Where's the contention? Todd > > Yes. There is a better way to model that. > > > > Oh, you wanted a suggestion. How about including a LOADS table that has (at > least) 3 colums > truck_id > cargo_id > active_flag > That way when cargo is moved to a different truck you add a new record to > the LOADS table and update the old one (setting the active_flag to false) > > Kevin > > -----Original Message----- > Sent: Thursday, November 06, 2003 9:45 AM > To: Multiple recipients of list ORACLE-L > > > I remember seeing this question asked on another forum some time back. I > dont like the solution the guy had and Im wondering how some of you might > solve problem. Im giving a low level generic example. > > Lets say you have a parent-child relationship. The parent table is 'TRUCKS' > and the child table is 'CARGO'. The foreign key to CARGO tells which truck > the cargo is loaded on. When the cargo is moved to another truck, the > foreign key is updated. > > I dont like this approach. it causes contention. what is a better way to > design this? > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: <[EMAIL PROTECTED] > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: Kevin Toepke > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: Todd Boss INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
