Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: CD storage (was No more Cinemaware stuff for Amiga !!!????) Message-ID: <121658@sun.Eng.Sun.COM> Date: 15 Aug 89 22:03:47 GMT References: <346@eagle.wesleyan.edu> <1523@ndmath.UUCP> <514@morgoth.UUCP> <121390@sun.Eng.Sun.COM>Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 44 In a previous article (Jonathan D. Trudel) writes: ->Define slow for me. I saw such a system set up on an IBM pc that ->my girlfriend's friend's husband was working on for a company down in ->the DC area (I don't remember the name of the company) and they are ->offering such a product as the one you describe. They are putting ->governmental records onto an optical disk and getting really reasonable ->data recovery from it. Considering that it replaces the previous ->microfiche technology, the access time is greatly improved. The only ->slowdown occurs for printing - normal photocopy processes are an order ->of magnitude faster than laser printing... Ok, my comment was that building the index was "slow", an operating CD ROM system is certainly "fast" by most definitions. Using your example, how are the records indexed? If they are simple keys like last names, or days of the week then you can build the index algorithmically and fairly quickly. If they are based on things like "All references to the FUJI project that involved funding decisions" which is the type of query one might like to make of the congressional record, someone has to read all of the text and make those connections manually. When an index is built that way, it can take months or years to do. Similarly, if you collected a whole bunch of stuff that was externally related like all of the Fish Disks, you get one index for free "find by VOlume #" but have to manually build the "find all demos, find all editors, etc" indexes by hand. Once these indexes have been built and the CD has been mastered, and a production CD is available. *Using* the data is very quick and convienient. ->I think that for many data retrieval applications that the access time I ->saw in such a system was within reason. GRanted, we work with ->high-speed computers all day long, but many people don't, and are ->willing to put up with what we might perceive as slowness. But then ->again, isn't that what people said about computers 20 or 30 years ago? For systems where you are watching an animation and the outcome of the animation is dependent on which parameters you set, the several possible outcomes need to be physically close because they must be recalled and decompressed in less that the time between when the first one was started and when it finishes. For just getting records, retrieval times on the order of 1 second aren't bad at all. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"