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

"Anne & Lynn Wheeler" <lynn_at_garlic.com> wrote in message news:ullc424ow.fsf_at_mail.comcast.net...
> "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.

Yes -- good. So, the issue of pointers is no longer a problem of any models represented in existing productss -- is that correct? Somehow this problem morphed into the thought that graph-based data models require this overhead. Thanks for clarifying.

> 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.

well said. I think some text book must be teaching this wrong as I have heard or read this over and over again that "the pointer issue" is intrinsic in some non-relational data models.

> 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.

If IBM would have fought Oracle by using IMS and evolved that product instead of writing DB2, ... anyway, they didn't. IMS, along with the IBM databases I work with, are still healthy sources of revenue for IBM and I never hear anyone talk about any current problem with pointers with any of these non-relational implementations. It's a non-issue now, right? --dawn

> --
> Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Received on Mon Dec 13 2004 - 12:35:03 CET