Here is a partial display of SQL Schema

DIS SCHEMA IDMSSQL FULL AS SYN
*+ STATUS = 0 SQLSTATE = 00000
CREATE SCHEMA IDMSSQL
*+ DATE CREATED 1999-10-15-13.13.04.665279 BY T999649
*+ DATE LAST UPDATED 1990-01-01-00.00.00.000000
*+ FOR SQL
DEFAULT AREA MAINSQL.TEMP
;
CREATE TABLE IDMSSQL.DUMMY
*+ DATE CREATED 1999-10-15-13.14.05.473588 BY
*+ DATE LAST UPDATED 1999-10-15-13.14.05.473588 BY T99999
( ID LONGINT NOT NULL
)
*+ DEFAULT INDEX ON DBKEY
*+ TABLE ID 1024
*+ TIMESTAMP ’1999-10-15-13.14.05.473588′
;
CREATE TABLE IDMSSQL.TIMESHEET
*+ DATE CREATED 1999-10-21-08.41.02.875253 BY T999993
*+ DATE LAST UPDATED 1999-10-21-08.41.02.875253 BY T9999
( UKE NUMERIC(2) NOT NULL,
DATO DATE NOT NULL WITH DEFAULT,
START TIME NOT NULL WITH DEFAULT,
END TIME NOT NULL WITH DEFAULT,
HOURS NUMERIC(4,2),
………

CA-IDMS implementation of E-R model as a CODASYL as well as relational database within the same DBMS has shown that the end user views are irrelevant. But the industry never noticed this because the product was not available in the Unix or Windows world.

Ignorance of database systems have contributed to a lot of utterly useless discussions in the industry in the last 10 years… ORM (Object Relational Mapping) is the worst by-product of that discussion! Sometimes, I wonder how people can miss something obvious…well,if people. believing Ptolmey belived that the earth was flat for 4000 years, then anything is possible today also!

In fact SQL can be used today for query against a NONSQL (CODASYL) db in IDMS. For example one could issue ‘SELECT * FROM DEPARTMENT d, EMPLOYEE where (“DEPT-EMPLOYEE”) and d.dept_id=100

Here the CODASYL set-name works as if we have provided a “d.dept_id= e.dept_id)

In some cases UPDATE also works (so long as CODAYL set is not involved)

UPDATE DEPARTMENT SET DEPT_NAME=”BBS” WHERE DEPT_ID=100 works and will use hash optimization for the dept_id, though DEPARTMENT is not a relational table at all.

In the modern world there is a tendency to reinvent the wheel. Now we have also reinvented a new name ‘NOSQL’.

‘SQL’ name has been misused all these years. SQL does not mean the database is relational but that is the impression spread by Oracle, MS/SQL, Sybase, Informix and all others. It was also very wrong to call the MS database as “SQL Server”, other than a marketing gimmick then.

RDBMS as such is trying to implement many things (unique identifier … Database KEY) behind the scene which has been a standard feature of CODASYL db and which has been declared ‘BAD’ by relational purists in the 1980s! (IDENTITY etc in MS/SQL).

RDBMS touted so much on relational theory of Dr Codd. All RDBMSs are built on top of INDEX-es. But indices are never part of the relational model. At the same time, all of them failed to implement any hashing for the keys. CA-IDMS was originally based on HASHed access for the primary (Index support was added later).

Bottomline is that SQL is just the access DML. Any non-relational system (old IMS inclusive) could have given SQL front-end support as done by CA-IDMS.

Now everyone is trying to do ORM mapping, NOSQL databases etc… A penalty for forgetting that the purpose of any commercial data processing is to store and retrive data from a store – which we call database!

I don’t know if it’s _specifically_ intended for use in RDBMSes, and I do know it is used outside of RDBMSes, but it’s ideal for implementing RDBMses because it provides transactional, persistent, high-performance key-value maps (aka associative arrays aka indexes). These are a fundamental building-block of OLTP-oriented RDBMSes.