Re: Quote from comp.object

Interesting Post. I was hoping if you had time you might expand on some points for me?

On Mar 2, 12:37 am, Anne & Lynn Wheeler <l..._at_garlic.com> wrote:
> Sampo Syreeni <d..._at_iki.fi> writes:
> > In the end such an organization would probably be faster than an IMS
> > database because every overhead that could be cut would have been,
> > yet higher level operations like multitable joins which allow for
> > cost amortization would have been properly declared in relational
> > syntax, and fully exploited. Such savings are not possible under the
> > interface offered by IMS, evenwhile they're the lifeblood of the RM.
>
> as i've mentioned before ... the exchange between the IMS group and
> the System/R group in the late 70s ... basically was that System/R had
> drastically increased system overhead while significantly reducing
> manual/human maintenance effort.

What exchange was this? Are you referring to informal discussion or groundswell opinion, or is there some form of documentation that I might cite?

>
> The trade-off was that IMS carried direct pointers as part of the
> database "data" ... were exposed to the database applications and had
> to be managed and dealt with. The relational System/R implementation
> had abstraction that did away with the exposed record pointers and
> therefor eliminated significant amount of human/manual/administrative
> effort dealing with the exposed record pointers. The System/R "costs"
> were an index implemented under the covers (below the abstraction
> interface) that significantly drove up the number of disk I/O
> operations needed to reach the desired information and also typically
> doubled the amount of physical disk space (for typical target
> applications of the period) ... but eliminated the manual costs of
> dealing with exposed record pointers.
>
> The change over in the 80s was general increase in people costs
> (driving up the human/manual/admistrative costs) and general decrease
> in computing hardware and resource costs ... changing human/hardware
> cost tradeoff decisions.
>
> There was also significant increase in amount real storage for typical
> configurations ... allowing much of the relational implementation
> index structure to be cached, mitigating the number of actual physical
> disk I/Os involved in dealing with the index structure, and
> significant reduction in disk space cost/bit muted the issue about
> doubling physical disk space.

Again, very interesting stuff. Do you know of any formal studies of this phenomena. I'd find any any such work invaluable. Kind regards, Jim.

>
> The next human constraint/bottleneck appears to be the intellectual
> effort related to "normalization". Some past studies have indicated
> that this is significant enuf that some large organizations were found
> with six thousand different RDBMS deployments ... where over 90precent
> of the information was common. The evoluation appears to have been
> that a RDBMS (potentially because of the normalization contraints) is
> relatively specific mission oriented (potentially a number of
> different applications, but still focused on a specific business
> mission). A some point, adding a somewhat different mission, it became
> simpler to take a subset of the original data and add just the
> additional items for the different mission. This repeatedly happening
> a number of times over a decade or more ... and the organization finds
> itself with 6000 very similar but still different deployments.
>
> There are still some number of significantly large business operations
> which continue to find they aren't able to justify the move from IMS
> type infrastructures to RDBMS operation. For the most part the value
> of the operation easily justifies both the hardware and people costs
> ... and the aggregate data may be so large ... and access patterns are
> sparse enough that there is not high probability that significant
> amounts of (RDBMS) index would already be cached, to eliminate needing
> several disk operations to arrive at the desired record. In some
> cases the issue may be that they have elapsed time constraints (like
> overnight batch windows) where elapsed processing time and number of
> (serially ordered) disk I/Os represents a significant consideration.
>
> Periodically there are statements that there may still be more
> aggregate data in these types of respositories than aggregate data
> existing in RDBMS repositories.
>
> misc. past posts mentioning system/rhttp://www.garlic.com/~lynn/subtopic.html#systemr
Received on Fri Mar 02 2007 - 14:00:27 CET