[comp.databases] SQL deficiencies & Ingres 6.3

cpl@bhpmrl.oz.au (Paul Lloyd) (12/18/90)

Pardon my pique, but perhaps I have been under some misapprehension:

I posted a query for SQL and/or Ingres gurus re the deficiencies in SQL and how
Ingres 6.3 with its two extensions might overcome some of them.  To date,
NOTHING!!  Is my query too trivial, or is the topic "taboo"?  I did think this 
was a discussion group, and the query is really genuine (we are in the process
of deciding on a RDBMS).  To refresh your memories, the query arose out of an article written by Pascal in Database Programming & Design (Oct. 90, p.75).

Should I start the ball rolling with my naive understanding?:
1.  SQL commenced life at IBM as a replacement for the more mathematically rigorous (and correct?) QUEL language, presumably with pretensions to easier 
query formulation by the not-so-technical user.  As a consequence, it shed 
some/many of the major attributes of a "pure" relational query language.  IBM's 
version was the starting point of the current SQL86 & SQL89 standards.  If I 
have this scenario substantially correct, what did it shed?  
2.  A recent discussion on  "limitations" in Informix's SQL was resolved by 
acknowledging that standard SQL does not have transendental functions such as 
exp(), ln(), sin(), etc. which are used in many fields outside of commerce.  
The discussion also pointed out that entering a mathematical expression as an 
argument in the SELECT clause was not supported (eg. SELECT col1, col2 * 
2.24/col3 ....).
3.  I can understand that standards, of a necessity, are always way behind the 
innovators and the market.  However, SQL89 has addressed referential integrity 
issues which are being extended in SQL2 to what it should be.  Likewise, the 
DROP, REVOKE, etc. commands are also part of SQL2 and I would have thought that 
by now most of the issues surrounding many of these have been finalized, leav-
ing only the esoteric issues to resolve.
4.  How does Ingres 6.3 overcome these current deficiencies?  Yes, I can see 
that its Knowledge Management Extension is an alternative (ie. non-standard) 
way of supporting referential integrity, domains, and business rules.  But,
because it is are non-standard it makes for a schema which is non-portable 
between systems, and asks CASE vendors to support a (or is it yet another) 
generic DBMS.  Ingres' Object Management Extension, however, seems to fall well 
outside the standards.  What deficiencies is this trying to cover?  (I must 
admit I like what it does, and can see some long term advantages for my 
science/engineering clients, however, Pascal's claims leave me puzzled.)

Hopefully,
--
     /\/\       Paul Lloyd, Superintendent Computer Systems 
    / / /\      BHP Research - Melbourne Laboratories
   / / /  \     245-273 Wellington Rd Mulgrave Vic 3170 AUSTRALIA
  / / / /\ \    Phone   :  +61-3-560-7066 ext:7375
  \ \/ / / /    Fax     :  +61-3-561-6709
   \  / / /     ACSnet  :  cpl@bhpmrl.oz.au
    \/\/\/      Internet:  cpl%bhpmrl.oz.au@uunet.uu.net