Re: Relational vs network vs hierarchic databases

From: Anne & Lynn Wheeler <lynn_at_garlic.com>
Date: Sat, 20 Nov 2004 09:15:11 -0700
Message-ID: <u4qjka44w.fsf_at_mail.comcast.net>


"Dan" <guntermann_at_verizon.com> writes:
> Traversing by pointers is very, very fast. There is not doubt about
> it. However, there is a huge downside to hardcoding a data model by
> using pointers and fixed data segments. This should be obvious.
>
> I believe what Laconic2 meant by saying "all other things equal" is
> that if we were to race a relational system and an IMS hierarchical
> system with *exactly* the same resources in terms of memory,
> processing power, platform characteristics, I/O capabilities,
> secondary storage, and inter-process communication overhead (which
> is probably not really possible), over fixed data access paths which
> correspond to how the hierarchy is formed in IMS, the IMS system
> would be and is faster (sub-second responses).

the big argument that i remember going on between stl/ims (bldg. 90) and sjr/systemr (and bldg. 28, just a couple miles away): http://www.garlic.com/~lynn/subtopic.html#systemr

was that there was a trade-off between the disk space of direct (physical) pointers in the 60s era database implementations (ims, hierarchical, network, etc) and relational using indexes. the comparisons in the late '70s was that the typical systemr implementation doubled the physical disk space (to handle the indexes) which was trade-off against the reduction in dba/sysadm people time managing the pointers (the issue of trade-off of physical pointers vis-a-vis physical disk space for indexes was common across the various '60s database implementations, regardless of information organization/model, hierarchical, network, etc).

note that the target of relational at the time was fairly striaght forward "flat", single table, bank account database .... with the account number the primary index ... not really taking into consideration infrastructures involving multiple tables, joins, etc.

as an undergraduate, i had worked on an onr-funded university library project that utilized bdam (& cics) ... which turns out to have been similar project going on at the same time at the NIH's NLM ... using the same technology (but much larger scale). I had an opportunity to look a NLM's implementation in much more detail a couple years ago with some stuff associated with UMLS ... a couple recent posts mentioning UMLS:
http://www.garlic.com/~lynn/2004f.html#7 The Network Data Model, foundation for Relational Model http://www.garlic.com/~lynn/2004l.html#52 Specifying all biz rules in relational data

There had been some work on mapping UMLS into RDBMS implementation ... the problem was that much of UMLS is non-uniform and frequently quite anomolous ... making anything but a very gross, high-level schema extremely difficult and people intensive .... for really complex, real-world data, the trade-off in operational sysadm/dba time was being traded-off against heavily front-loaded people time associated with normalization .... with the difference in physical disk-space requirements (for indexes) being ignored.

In any case, at that time, NLM was still using the original BDAM implementation (from the late '60s).

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Received on Sat Nov 20 2004 - 17:15:11 CET

Original text of this message