Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!grad2.cis.upenn.edu!aaron
From: aaron@grad2.cis.upenn.edu (Aaron Watters)
Newsgroups: comp.databases
Subject: Re: outerjoins
Message-ID: <28793@netnews.upenn.edu>
Date: 24 Aug 90 12:52:12 GMT
References: <28462@netnews.upenn.edu> <8720@cognos.UUCP>
Sender: news@netnews.upenn.edu
Reply-To: aaron@grad2.cis.upenn.edu.UUCP (Aaron Watters)
Organization: University of Pennsylvania
Lines: 18

In article <8720@cognos.UUCP> garyp@cognos.UUCP (Gary Puckering) writes:
>
>The outer join I've described here, where unmatched rows in the
>leftmost table are preserved, seems to be the most useful of the
>various forms of outer join.  The need for preserving unmatched rows
>in the left-hand table, or in both tables, seems far less
>prevalent.  I can't even think of any good examples off the top of
>my head.  Can anyone else?

Well, if you have two tables (say Faculty and Student) sharing
a common key (SS#) and representing the same kind of object (person)
but having different attribute sets ([ss#, department, status] and
[ss#, year, phone] respectively]) you might want to create a
`union' of these tables, listing all faculty and students.
However, if we assume that ss# identifies an individual uniquely
you might want any entries with the same ss# to be combined.

This is a hypothetical example for the `both table' case.	-aaron.