Date:         Sun, 31 Aug 1997 06:20:16 GMT
Reply-To:     doliov@NOWHERE.COM
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         doliov@NOWHERE.COM
Organization: West Coast Online, Inc.
Subject:      Re: SAS for Data Warehousing under UNIX systems

Jay L. Stevens <jstevens@PRUDENTIAL.COM> wrote:
: SAS handles warehousing just fine.  I'm not into the 500 GB range (just
: right around or under 75 GB.  If most of your (God help me if I use the
: term) "Data mining" is being done with SAS, and your MIS is being
: generated with SAS, and your statistical analytics are being driven with
: SAS, why in the world would you want to add another layer of complexity
: (i.e. a different data store) to the problem?  I'd like to hear from
 
: In the end, the term "relational" is really a term for the design of the
: data structures not a DBMS.  You can put a relational design into SAS
: with no problem. Perfectly "normalized" data, however, often does not
: lend itself to analytical, decision support problems.  In fact the whold
: relational concept works much better when dealing with TRANSACTION based
: systems not decision support type systems.
 
IMHO, you are both right and wrong.  what many are trying to achieve is a
marriage of decision support with (dare I say, "real-time") transactions.
e.g. order for 500K shares of company xyz just came in - should your
buy/sell decision which was made five minutes earlier be changed. e.g. #2,
retail credit card user john doe with a spotty credit history is
attempting a purchase which will exceed the fixed credit limit by 50%.
should the computer send out an approved or not approved message?
 
so now as an info technologist, you have to ask, how can two historically
separate functions and technologies be joined?  you certainly wouldn't
want to be feeding transactions into SAS.  At the same time, you don't
want to attempt a table join in ORACLE when the tables are large, let's
say, combined, 500G of data.  it doesn't take long to crash ORACLE (or
Sybase or Informix or whatever RDBMS you happen to have) on any platform.
So what do you do?  I don't think the original poster's problem has an
either/or answer.  the answers are going to be site and function specific
on which applications will best meet the needs of the business.  it's true
that SAS can do much more than it is generally thought capable of doing.
it's also true that SAS does a lot more than it hsould be doing, in many
situations.
 
equivocally,
steve doliov