Re: Flat Query

"Anne & Lynn Wheeler" <lynn_at_garlic.com> wrote in message news:m3ek6noo1t.fsf_at_lhwlinux.garlic.com...
> "David Cressey" <david.cressey_at_earthlink.net> writes:
> > Only if the record's addresses could be computed (or pointed to).
> > In general, the only kinds of unindexed files whose record address
> > was computable were fixed length records. And in general, fixed
> > lentgth records corresponded to flat files.
> >
> > Sure you can come up with exceptions. But i'm describing the
> > general scenario in which that language gained usage.
>
> it was also somewhat the battle in the 70s that went on between the
> stl 60s physical database people ... and the sjr system/r people
> ... original relational/sql
> http://www.garlic.com/~lynn/subtopic.html#systemr
>
> i.e. the phsycial database ... had records linked to other records
> ... where the linking was done by physical record pointers that were
> fields that were part of the record data ... these weren't traditional
> flat file ... but record location semantics was exposed.
>
> one of the points of system/r effort was to abstract away the reoord
> pointers ... by using indexing. the stl people claimed that system/r
> doubled the physical disk space (for the indexes) along with
> significant increase in processing overhead ... associated with all
> the index processing gorp. the sjr people claimed that system/r
> eliminated a lot of human effort that went into administrative and
> rebuilding efforts associated with the embedded record pointers. I
> did some of the system/r code ... but i also did some of the code for
> various other projects ... so I wasn't particularly on one side or
> anther.
>
> the 80s saw 1) big demand increase for online information ... putting
> pressure on scarce database people resources, 2) significant increase
> in physical disk space and decrease in price/bit, and 3) large
> increase in processor memory that could be used for caching indexes.
>
> The disk technology change drastically reduced the perceived cost of
> the extra index structures ... and the significant processor memory
> increses allowed significant caching ... which in turn reduced the
> perceived overhead of index processing.
>
Good Summary.

About the only place I still see the argument between exposed pointers and indexes is... right here in the comp.databases.theory newsgroup, where our resident gadfly is still trying to persuade us to go back to pointers, and start over!

Branching off on a tangent... By collecting all the pointers in indexes, and putting them under control of a subsystem of the DBMS, it becomes possible to move a table (perhaps to another disk), and update all the pointers in the indexes that need it.

By contrast, in the World wide web, there is, in general, no way of knowing how many hyperlinks will be broken if an object is moved from one URL to another, or how to fix them. People seem to be willing to live with this decifiency, but I suspect that their patience will eventually run out. Received on Sat Oct 15 2005 - 15:01:20 CEST