Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!tfic.bc.ca!clh
From: clh@tfic.bc.ca (Chris Hermansen)
Newsgroups: comp.databases
Subject: Re: INFORMIX SQL functions
Keywords: informix sql
Message-ID: <1990Nov30.165726.27488@tfic.bc.ca>
Date: 30 Nov 90 16:57:26 GMT
References: <1990Nov22.210621.7930@tfic.bc.ca> <19917@oolong.la.locus.com> <1990Nov28.222220.20110@tfic.bc.ca> <20081@oolong.la.locus.com>
Reply-To: clh@tacitus.UUCP (Chris Hermansen)
Organization: Timberline Forest Inventory Consultants
Lines: 57

In article <20081@oolong.la.locus.com> jfr@locus.com (Jon Rosen) writes:
>In article <1990Nov28.222220.20110@tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
>>
>>(Stuff deleted about SQL and SQL functions)
>>
>>DATE functions, for !@#$%^ sake!!!  Yessir, let's let the user convert

[stuff deleted]

>One more point... Your comment on date functions is reasonable from your
>prospective as a person interested in numeric processing... However,
>the SQL standards mostly came from IBM's work in the 70's and into the
>80's in DB2 and as most of us know, IBM's bias is commercial data
>processing, not numerical analysis... After all, that is where they 
>sell most of their iron... IBM added a complete set of DATE and TIME
>functions to DB2 pretty early... This allows commercial users to do
>things like compare dates accurately, add days to a date (for things
>like payment aging and checking if accounts are delinquent) which are
>about as important to commercial users as transcendental functions are
>to engineers and scientists... So, while I understand your frustration
>with most SQL's (and particularly Informix's) lack of numeric functions,
>don't flame the poor commercial user because s/he just might respond:
>"Cosine? Oh sure, just what we need, a way to turn a number from 0-360
>into a number from 0-1!"   

I agree to some extent; I must admit I've never seen a financial type
compute a cosine.  However, there are PLENTY of financial types of
analysis that require the use of exp() or ln() or most especially sqrt().

>The reality is we need ALL KINDS of function capabilities in SQL. I hope
>the standards guys are listening...

Exactly!  The message to get across to DBMS designers is that ad-hoc
query tools like ISQL (as opposed to full-fledged design systems like 4GL)
are going to get used in an ad-hoc fashion, and flexibility is the key
to that use.

I think the focus is important, too.  One of the things I like most about
Informix's products is that they don't try to make one "all things to all
people" product - thus I don't have to learn all the ins and outs of a
super-duper backend just to muck with some data (for example).

So: look at SQL.  It's a relatively simple (primitive??) query language.
Let's consider its suitability for use by a wider audience, but let's
not confuse that with turning it into a real-time programming language
suitable for tracking missiles.

>Jon Rosen

Thanks for your time & interest, people.

Chris Hermansen                         Timberline Forest Inventory Consultants
Voice: 1 604 733 0731                   302 - 958 West 8th Avenue
FAX:   1 604 733 0634                   Vancouver B.C. CANADA
clh@tfic.bc.ca                          V5Z 1E5

C'est ma facon de parler.


Brought to you by Super Global Mega Corp .com