Re: Generalised approach to storing address details

paul c <toledobythesea_at_oohay.ac> writes:
> Look for some other sources. It shouldn't be hard to see that Codd's
> early effort was not part of a concerted research effort and it
> shouldn't be hard to see that one of his big interests was to show
> what adhoc, illogical quicksand the typical, physically-oriented
> database efforts of the day were built on, such as IBM's IMS and Vandl
> and all the Cincom and IDS stuff. It wasn't so much cost that Codd
> was interested in but rather dispelling some of the nonsense. In many
> endeavours, dispelling nonsense can reduce costs. Obviously savings
> would arise from one of his main points, the idea of sharing data
> rather than replicating it as those "DB" products did, but the fact
> was that at that time, the bulk of commercial data was not even
> maintained by so-called dbms'es, rather file-based applications.

there were some arguments between stl/ims people and sjr/systemr people that i've mentioned several times before ... misc. past posts mentioning system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

the ims people claiming that (system/r) built-in index doubled the physical disk space ... and drastically increased the number of disk i/os to access the data (as part of processing the index)

the system/r people claiming that the built in index eliminated a lot of the manual intensive effort required to manage the direct (physical) record pointers found in IMS data (in some sense the implicit index used by the relational implementation allowed for eliminating direct record pointers in the 60s physical database implementations)

the trade-off was the manual IMS effort vis-a-vis disk and processing overhead in system/r.

the transition somewhat came in the mid-80s ... as people became more expensive and skilled resources became scarce ... at the same time disk space was rapidly increasing and the price/bit was rapidly decreasing. at the same time, the amount of real memory in systems was rapidly increasing ... which allowed for significant caching of indexes. the combination met the space/cost for the indexes was rapdily declining and the caching significantly reduced the index processing overhead. the manual/computer cost trade-offs changed ... but in some cases just the lack of the manual skills met not being able to automate (the difference between automated or not automated can be much larger than the infrastructure costs).

note however, there continue to be periodic claims that in commercial environments, IMS databases still continue to manage much more data ... than the amount of data in rdbms databases.

also, while relational may have somewhat improved application data sharing ... various RDBMS issues, like normalization can still be quite daunting ... especially if you are dealing with widely differing projects. something over a decade ago, we looked at a number of large enterprises ... and one specific example wasn't too unusual ... where an enterprise found they had something like 6000 different RDBMS ... and they believed that well over 90percent of the data was common across the 6000 different RDBMS. Received on Wed Dec 13 2006 - 02:47:23 CET