In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: >[EMAIL PROTECTED] wrote: >> hmmm...I wonder if a checksum could have been used for an index. >> It would make a change to any file immediately flagged. >> The owners of those files would have to be the people who >> answered the phones. I don't remember how nor who generated >> our phone books. > >the combination of sorting the file and having the letter frequency >distribution for names provided an implicit index with no disk space >index overhead. this was still in the era when the physical database >guys (stl, ims, etc) were dis'ing the original relational/sql activity >http://www.garlic.com/~lynn/subtopic.html#systemr > >as the real relational indexes was doubling the physical disk space >required ... back in the days when that was important. > >radix search with additional knowledge of actual letter frequency >distribution for names met that within 2-3 probes, things would be >within the correct physical record. relational index search by itself >could require several physical disk reads ... just of the index ... >before even getting around to physical read of the actual data.
Did you also have to index ala phone number? Using the data base for the actual phone switching would have the side effect of keeping the listing up-to-date. IBM also had thousands of employees; I would suspect 50% more for phones not associated with a human but a facility. > >this was still all late 70s. the thing that help turn the tide for >relational in the 80s ... was > >!) large increase in available disk space ... so the index space >requirements became much less of an issue Cheaper memory would also help. The wrong page would always be the one in core. > >2) large increase in real storage ... being able to cache indexes. in >memory so there was much less disk i/o penalty for doing index lookup. ISTR something about arranging the index and what it pointed to carefully...or maybe I'm remembering a dream I had one night. /BAH
