Addresses is the parent (so it will not be orphaned). It's up to the
business rules to decide to keep addresses when a employee get fired or not.
If cleaning is required then it's easy to do.

Many of the application these days like to keep a table with all US
addresses.

The idea is always to simplify the database design.

Regards,

Waleed

-----Original Message-----
Sent: Wednesday, July 31, 2002 5:58 PM
To: Multiple recipients of list ORACLE-L


here is an argument against this solution:

in current economy, some day you'll have a lay-off, and you'd want to
"delete" an employee (you will be laying off employees - not addresses,
right?), then you'll have to take "additional" care not to leave "orphan"
addresses, and all this headache, only because of the wrong design in the
first place.

Igor Neyman, OCP DBA
[EMAIL PROTECTED]


----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, July 31, 2002 5:04 PM


> Supplier
> ========
> Supplier_id is pk
> col2
> col3
> supplier_address_id fk references addresses (address_id)
>
> Employee
> =========
> Employee_id is PK
> col2
> col3
> employee_address_id fk references addresses (address_id)
>
>
> Addresses
> =========
> Address_id is PK
> zip code
> street
> etc
>
>
> The address table is the parent.
>
> Regards,
>
> Waleed
>
>
>
> -----Original Message-----
> Sent: Wednesday, July 31, 2002 4:43 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Good day, all:
>
> Am curious to hear opinions on how to model a child table that has
multiple
> parent tables (i.e., foreign key to multiple parents)
>
> Example:
> There's a table that stores Addresses (table ADDRESS) for both employees
> (table EMPLOYEE) and suppliers (table SUPPLIER).
>
> Each of these tables has a Primary Key field called ID.
>
> One way to set this up would be for the ADDRESS table to have 2 fields,
> EMPLOYEE_ID and SUPPLIER_ID, which would be mutually exclusive (i.e., one
or
> the other, to indicate the parent record of the address).
>
> Another solutions if for the ADDRESS table to have two fields to indicate
> the parent table name and parent table pk value.
>
> The first method enables me (the dba) to create foreign keys from the
> address table to each of the parent tables to validate data. The second
> method does not enable me to create such foreign keys (leaving it to the
> developers to validate date and insure referential integrity) but would
also
> easily facilitate the addition of other parent tables (e.g., CONTRACTOR,
> VENDOR, etc.) without altering the ADDRESS table itself.
>
> Any and all thoughts, comments, opinions, experiences are most welcome.
>
> Thanks!
> bill magaliff
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Magaliff, Bill
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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.com
> --
> Author: Khedr, Waleed
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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.com
-- 
Author: Igor Neyman
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
-- 
Author: Khedr, Waleed
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).

Reply via email to