Re: Relational Databases Lack Relationships

Eric <eric_at_deptj.eu> writes:
> Aside from needing to find out what on earth they mean by
> "semi-structured" and "ad-hoc, exceptional relationships", has anyone
> ever heard, from any other source, that codifying paper forms and tabular
> structures is what relational databases were designed to do?

I got roped into doing doing part of the implementation for original sql/relational ... Codd's office was floor above mine.

they were somewhat competing with IMS for efficient financial transactions (as early adopter) and table optimization allowed single record to be fetched using account number index, that contained all the fields for performing financial transactions.

The IMS group still criticized the implementation as requiring twice the disk space (for the table index) as IMS with its direct record pointers ... and 4-5 the disk I/Os (doing index lookup). The counter was that IMS required significant manual maintenance to go through and update all the exposed record pointers anytime there was even trivial, minor change in layout. To some extent the trade-offs inverted in the 80s when cost of disk space enormously dropped and size of memories significantly increased ... allowing significant amount of index caching (reducing physical disk i/os). One of the original customer joint studies/pilots was with large financial institution.

The next generation "official" DBMS was called EAGLE. With the corporation preoccupied with EAGLE, we were able to do technology transfer to Endicott and get it released as SQL/DS. Later when EAGLE implodes, they ask how long could it would take to make it availble ... which is eventually released as DB2.

At the same time, I got sucked into doing another implementation that directly instantiated all relationships (done fpr internal chip design tools group) ... every field effectively became separate indexed record and every relationship became separate indexed record. It could require 7-10 times the disk space as the original sql/implementation and significant more disk i/os (access index for a field, then read the field, then access the indexes for all its possible relationships, read the relationships, and then access all the indexes for each field for each relationship and then read all those fields.)

For really large amounts of complex data ... there was cross-over where table joins became more expensive/overhead than directly instantiating all fields and relationships (with forest of indexes)

-- 
virtualization experience starting Jan1968, online at home since Mar1970