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>
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...
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
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.