LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (June 2008, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 12 Jun 2008 17:53:35 -0400
Reply-To:     "Howard Schreier <hs AT dc-sug DOT org>"
              <schreier.junk.mail@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Howard Schreier <hs AT dc-sug DOT org>"
              <schreier.junk.mail@GMAIL.COM>
Subject:      Re: Question on proc sql

On Thu, 12 Jun 2008 10:40:22 -0400, Sigurd Hermansen <HERMANS1@WESTAT.COM> wrote:

>Lorna: >I've just found a few free minutes to respond to your question about SAS >SQL ... > >You can trust me, the original SQLHead on SAS-L,

Are you sure? I started posting SQL solutions on SAS-L in about 1991.

>to give you an unbiased >and objective appraisal of SAS SQL's virtues vs. that other dirty Data >step quasi-procedural language that SAS still supports. Just replace >"Mac" with "SQL" and "PC" with "Data step" in those TV commercials and >you'll have the drift of my idea about SAS SQL vs. the SAS Data step >language. > >SQL currently dominates the arena of database programming languages. >That doesn't make SQL an ideal instance of a logic-set language, but it >has substantial advantages in some respects over languages that process >records and fields (or even those that process obs and variables). To >name a few, > >1. SQL operates on relations (views, tables, etc.), thus freeing >database programmers from the risky business of building explicit loops, >while Data steps allow a confusing mixture of step-by-step processes >(e.g., a sequence of assignments) and before and after operations (e.g., >ATTRIBUTE and KEEP statements); >2. A SQL SELECT statement always produces (yields) a relation, allowing >nesting of encapsulated SQL statements, while Data steps accumulate a >trail of datasets or views; >3. SQL allows references to a dataset/view and variable, making it >easier to figure out sources of values, while DATA steps don't; >4. SQL doesn't require a programmer to sort datasets and remains >agnostic to ordering of tuples (obs) and attributes (variables), unlike >the Data step; >5. SQL joins appear several levels higher on the database programming >tree of evolution than Data step merges (think sea otter vs. alligator); >6. SAS SQL segues cleanly into SAS/Access to external databases; >7. SAS SQL programmers have more fun. > >Now I must add that SAS-L has a number of very clever and creative >programmers who make good use of the Turing-complete features of the SAS >Data step. They may see some of what I see as disadvantages of the Data >step as advantages. It pays to learn both, and to continue learning >both. Really good programmers don't use the same set of Data step or SQL >operations in the same way that they used them a few years earlier. >S > >-----Original Message----- >From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of >Simon, Lorna >Sent: Monday, June 09, 2008 10:36 AM >To: SAS-L@LISTSERV.UGA.EDU >Subject: Question on proc sql > > >I have a question about sql - what is the advantage of learning it? Are >there things you can do in sql that you can't do in a regular sas data >step?


Back to: Top of message | Previous page | Main SAS-L page