home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / bit / listserv / dbasel / 932 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.1 KB  |  38 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!paladin.american.edu!auvm!SNYCENVM.BITNET!OGDENEB
  3. Organization: State University of New York - Central Administration
  4. Message-ID: <DBASE-L%92090807564310@NMSUVM1.BITNET>
  5. Newsgroups: bit.listserv.dbase-l
  6. Date:         Tue, 8 Sep 1992 09:29:54 EST
  7. Sender:       "Discussion on the use of the dBase language and related
  8.               dialects" <DBASE-L@NMSUVM1.BITNET>
  9. From:         EVERETT OGDEN <OGDENEB@SNYCENVM.BITNET>
  10. Subject:      Re: dbase questions + ASCII --> dbase
  11. In-Reply-To:  Message of Tue, 8 Sep 1992 06:44:06 GMT from <vanloon@CWI.NL>
  12. Lines: 24
  13.  
  14. Maarten van Loon asked (among other things) why dBASE files use
  15. fixed-length fields, padded with spaces, rather than just storing the
  16. data as in an ASCII file.  He says that seems inefficient.  Inefficient
  17. for storage space, yes, but very efficient for speed.  Suppose you have
  18. a database of several million records, and you want to look at record
  19. 3,579,545.  dBASE knows how big a record is, so a quick calculation
  20. tells it just where to look in that multimegabyte file.  With a plain
  21. sequential file, you'd have to scan through the file from the head (an
  22. indexed sequential file would improve things some).
  23.  
  24. More importantly, look what happens when you want to modify a record.
  25. Since the new version will take exactly the same space as the old, dBASE
  26. can change just that part of the file.  But with a sequential file, you
  27. have to either remove the old version and insert the new (and rewrite
  28. the file from the record's position to the end), or tack any changed
  29. records onto the end of the file, eventually leaving a lot of dead space
  30. in the file and requiring a good indexing system to keep track of it.
  31. Word processors generally work with sequential files and use one of the
  32. latter two methods (the only one I know of that used the last method was
  33. DisplayWrite).  But you don't generally load multimegabyte files into a
  34. word processor.  If you do, you'll find that edits and even movement
  35. through the file are very slow indeed.
  36.  
  37.       Everett Ogden    ogdeneb@snycenvm.bitnet
  38.