Date:         Mon, 6 Nov 2006 12:33:07 -0500
Reply-To:     "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Subject:      Re: a special sql query

On Fri, 3 Nov 2006 12:42:49 -0800, Anonymous <anonymous.nospam@HOTMAIL.COM>
wrote:

This was in response to a solution I suggested which included a NATURAL
JOIN. I sometimes do that just for brevity when the coding of an equi-join
key is incidental to the issue at hand.

>Please note that natural joins are not recommended in production code.
>See the following thread for more detailed information...
>
>http://forums.oracle.com/forums/thread.jspa?threadID=440287

The reasoning is that after code is written and tested, a column might be
added added to a table which name-matches a column in another table, causing
those columns to be inappropriately absorbed into the composite key (which
is implicit in a natural join).

It's a valid point, but it seems to me that there is a counter-argument. If
one uses natural joins and if a composite key is modified in any way (add a
column, remove a column, combine two columns into one), view code will adapt
itself and not require modification.

I can't universally endorse one position or the other. I think it depends on
circumstances.

Also, the same essential issues arises with a lot of implicit constructs,
both in SQL and in other parts of SAS. For example, I rarely if ever use the
double-hyphen list form (eg, KEEP SOMEVAR--SOMEOTHERVAR) because I find
variable order to be too unstable and likely to change as an unintended
consequence of code modifications.