Re: 1GB Tables as Classes, or Tables as Types, and all that refuted

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> writes:
> Name one precise problem that the hierarchical DBMS's had that is
> now present for anyone using an XML model of data. It's time to
> drop the flawed notion that data graphs have some inherent problems.
> One can build terrible database management systems based on graphs
> or good ones. The model, itself, is useful and never was abandoned
> in reality (or in Reality, a database from the company Northgate --
> McDonnell-Douglas and variants of the company kept this graph-based
> solution active since the early 70's as the Microdata company, and
> it is still being sold and used today)
>
> Graph-based data models have survived the Relational Database trend and will
> now get a new push given that more people now understand -- and even more
> will! -- that RDBMS's have no better theorectical basis than graph-based
> database management tools. And, PA-LEASE STOP calling them "Network" and
> "Hierarchical" -- they are graphs and trees. No other niche in the computer
> industry has problems using mathematical terms "graphs" and "trees". Using
> a mathematical term ("relations") for your preferred data model, while
> avoiding the mathematical terms for the others is way too obvious a form of
> spin and, by golly, it worked for a couple of decades, dag nab it (thus
> holding back our industry unnecessarily, methinks), but the time has come to
> AT LEAST get away from the N & H terms. --dawn

note that the arguments that i remember going on between stl/bldg.90 and sjr/bldg.28 wasn't so much about the information structure. the hierarchical and network databases of the 60s used physical pointers and system/r (first rdbms)
http://www.garlic.com/~lynn/subtopic.html#systemr

used indexes.

the argument was the trade-off between the human advministrative effort to maintain the physical pointers (which was subsumed in large part by system/r indexes) and the indexes typically doubling the physical disk spaced occupied by the database (because of the indexes) ... as well as the index lookup being slower than direct pointers. The issue was could you trade-off processing resources and disk space resources against the manual administrative efforts.

during the 70s and 80s, the manual resources became scarcer and more expensive while processing and disk space became much more plentiful and less expensive. also with large and less expensive real memories of the 80s, it was possible to cache some amount of the indexes, off-setting some amount of the index processing penalty.

however, physical pointers (used in the 60s) aren't necessarily intrinsicly a characteristic of the information organization ... just a characteristic of the resource trade-off implementation circumstances of the period.

there are still quite a few large, major ims installations still in existance
http://www-306.ibm.com/software/data/ims/

from above:

IBM's premier transactional and hierarchical database management system for critical on-line operational and e-business applications and data, enabling Information Integration, Management, and Scalability

and
http://search390.techtarget.com/featuredTopic/0,290042,sid10_gci990489,00.html

When most mainframers hear Web-enabling a database, they think connecting DB2 to the Web. But IMS, IBM's older database, is just as Web worthy. To hear more about Webifying an IMS database, check out this Webcast with Jim Keohane.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/