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 (November 1997, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 18 Nov 1997 18:29:01 -0500
Reply-To:     "Jay L. Stevens" <jstevens@PRUDENTIAL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         "Jay L. Stevens" <jstevens@PRUDENTIAL.COM>
Subject:      Re: Justification for Oracle
Comments: To: Mike Davenport <Mike.Davenport@RICHMOND.PPDI.COM>
Content-Type: text/plain; charset=us-ascii

> If you want to set up a double entry system Oracle is much better. (i have > done it in both systems). In fact data entry via Oracle is in general > eaiser. For tracking changes to data (if you need to determine when and who > added, changed or deleted a record or field) Oracle is far and away a better > choice than SAS (Again I have set up systems in both). >

Indeed you're probably correct. In fact, in my original post, I actually recommended Oracle and their development tools to those who are looking to build operational systems (rather than analytical/decision support systems). I'm sure there are some SAS-L'ers who are vehement AF supporters who would disagree with you, though.

> NOT. > SAS/ACCESS to Oracle makes the access of Oracle table to SAS datasets > transparent >

To quote a frequent poster and a 20-year SAS veteran: "Not only is it not transparent, but the Oracle baggage slows down the whole train."

I have to agree. In a decision support environment, why should you even have to go through the headache of defining SAS/Access view descriptors or writing Proc SQL passthru code when SAS can provide the same functionality without Oracle. No matter which SAS/Access interface you use, it only makes logical sense that a) Accessing your Oracle data via Sas/Access or other query interface then b) cramming that result set of data through an I/O pipe into SAS for reporting and analysis is going to be slower than allowing SAS to access the data directly.

> In general SAS is probably the best report and analysis tool to use. Oracle > is a relational database while SAS is NOT. >

This is exactly the point. When you are interested in reporting and analysis (i.e. data warehousing, data-mining application(s), why in the world do you want to slow down the process with ReDo loggging and Rollback segments, etc., etc. ad-nauseum, when you don't need that extra baggage. You have to work extra hard just to get Oracle to stop doing these things so it will perform.

> You need to evaluate your needs for a mainframe relational database (i know > there is a PC version). If you need the things a relational database > provides then Oracle is one of the best choices. >

Again, this is the point. The relational database vendors realized a few years ago that this thing now called Data-Mining and Data Warehousing (something SAS has been good at for many years) is a hot topic with many potential dollars involved. So...they pulled out their old relational transaction systems and said, Ta DA! A data warehouse repository. You can use SAS but still keep the good old relational database alive and kicking! I seriously question the value of the relational model in a Decision Support environment.

Jay L. Stevens AVP Portfolio Analysis Prudential Bank

jstevens@prudential.com


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