You have two options: Use foreign keys directly in the Order table OR use a
join table (link table). Either will work, I would think, with a good
persistence manager, but the first scenario is more likely to work with all O/R
persistence managers.
Using address foreign keys directly in the Order table (scenario 1) will be more
performant (one less table to join). Using a link table (scenario 2) gives you
more flexibility.
Also this all depends on support for cascading deletes, which changes the
organization considerably. In that case you'll need an Address table with
foreign keys pointing back to the Order table.
Scenario 1: Using foreign keys directly in the Order table.
********************************************
Order Table
-------------
orderID (pk)
shippingAddress (fk to addressID in Address table)
billingAddress (fk to addressID in Address table)
Address Table
---------------
addressID (pk)
street,
city
state
zip
Scenario 2: Using a link table
***************************
Order Table
-----------
orderID (pk)
orderAddress (fk to ID in OrderAddressLink Table)
OrderAddressLink Table
-----------------------
ID (pk)
orderID (fk to orderID in Order Table)
addressID (fk to addressID in Address Table)
addressType (char [30] describes the type of address shipping or billing.)
Address Table
---------------
addressID
street,
city
state,
zip
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.EjbNow.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".
