Date: Wed, 12 Jul 2000 17:02:54 -0400
Reply-To: "TAN, ALBERT Y. (AIT)" <ALBERT.Y.TAN@MSG.AMERITECH.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "TAN, ALBERT Y. (AIT)" <ALBERT.Y.TAN@MSG.AMERITECH.COM>
Subject: Re: INSERT SASDATASETS into ORACLE Tables
Content-Type: text/plain; charset="iso-8859-1"
You can't forget one for the other. On the forefront of data mining and
statistical modeling, SAS may easily beat other DB software. It is also
very handy to use SAS data set and macro languages to write custom reports.
However, SAS is not appropriate for day-to-day operational data storage and
user query. Here is an example. If your user changed your data from
on-line screen or your programmer touch the wrong key and delete your whole
SAS dataset, you may find it hard to recover it unless you have another copy
of the data set somewhere else. If both events happen the same time, say,
one user just added (appended) a sub dataset to your dataset and the change
becomes permanent. If your programmer now deletes the dataset, can you
recover it in a point to time way?
The best thing is to running SAS as a reporting and statistical analysis
tool against database such as DB2, INFORMIX, or ORACLE.
Albert
Your personal SAS questions are always welcome!!!
-----Original Message-----
From: Mauro Morandin [mailto:mauro.morandin@TISCALINET.IT]
Sent: Wednesday, July 12, 2000 3:21 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: INSERT SASDATASETS into ORACLE Tables
Scott,
I don't believe that SAS has all the answers! SAS is really fast when doing
stupid things
on huge amounts of data -> I don't think there is anything which can beat a
PROC MEANS
or a data step merge in terms of efficiency........but have you ever tried
to do a star schema join
with SAS on multiple keys in one single view with SAS ... forget it ... use
Oracle.
SAS has done a lot in improving PROC SQL, it's becoming faster and more
efficient with every
new release of SAS, I haven't tried it on a big database in V8. In V6 I
often had out of
memory errors using PROC SQL... I had to find other less memory hungry
solutions like a
pair of SET and SET KEY=... I think you are better off understanding the
strength of both
systems and using them at their best. Cost may be an issue too.
Ciao.
Mauro.
--
-------------------------------------------------------
MATRIX
Castelfranco Veneto - ITALY
email: mauro.morandin@tiscalinet.it
-------------------------------------------------------
"Scott Chapal" <schapal@mail.jonesctr.org> ha scritto nel messaggio
news:p1z0zw59r.fsf@mail.jonesctr.org...
> paul_dorfman@HOTMAIL.COM (Paul Dorfman) writes:
>
> > Welcome to the wonderful world of the stellar Oracle performance! I hope
it
> > is worth those M$$ that migrated to the Oracle coffers. On a
constructive
> > note, please let me suggest that you should read the excellent SUGI 25
paper
> > by our fellow sasler Dianne Rhodes "Migrate to ORACLE? I need my SAS
> > Software!"? Suffices it to say that its conclusion consists of but a
single
> > sentence: "Stick with SAS".
>
> Please elaborate. We are also evaluating the coexistence of SAS and
Oracle.
> Is the paper available on-line somewhere? I searched www.sas.com but
didn't
> see it.
>
> > >I'm wondering if there are any tricks to tune this statement
> > >in order to decrease the run time (estimations are approx
> > >30h for 10000000 observations with 2 attributes each).
>
> How bad is this? Compared to what?
>
> Thanks.
> --
> Scott E. Chapal
| 
