home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / dbasel / 1252 < prev    next >
Encoding:
Text File  |  1992-11-24  |  2.1 KB  |  48 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!auvm!UTHSCSA.BITNET!BURNFIELD
  3. Original_To:  DBASE-L
  4. Original_cc:  BURNFIELD
  5. Message-ID: <DBASE-L%92112318235154@TECMTYVM.MTY.ITESM.MX>
  6. Newsgroups: bit.listserv.dbase-l
  7. Date:         Mon, 23 Nov 1992 09:53:00 CDT
  8. Sender:       "Discussion on the use of the dBase language and related
  9.               dialects" <DBASE-L@NMSUVM1.BITNET>
  10. From:         BURNFIELD@UTHSCSA.BITNET
  11. Subject:      RE: Indexing Prohlem
  12. Lines: 34
  13.  
  14. One approach is to look at your possible seek variables and see if there
  15. are any combinations that will come up more frequently than the others and
  16. build your indexes to more efficiently handle those cases. If the search
  17. criteria doesn't quite match your indexes then you may be able to use one
  18. of them eliminate a good portion of the database and use a WHILE loop to
  19. get at the rest of the records. For example, suppose you have an index
  20. whose expression is SSN+DTOS(date) and the user wants to search by SSN
  21. + organization + whatever. You could eliminate a great portion of the
  22. database by using the SSN+date index and soft seek on SSN. You could then:
  23.  
  24. DO WHILE SSN = srchssn
  25.    if DB->org = srchorg and DB->Whatever = srchwhatever
  26.       ... process this record
  27.    endif
  28. Enddo
  29.  
  30. This way you wouldn't have to plan for every combination; however, you may
  31. be able to come up with some indexes that will contain at least one of the
  32. search items the user is looking for most of the time. If you get real lucky
  33. and 2 search fields match indexes you've set up, choose the one that will
  34. eliminate the most records.
  35.  
  36. Another approach that you might consider is to index the database on the
  37. fly, based on the search criteria that the user entered and delete that
  38. file after it's no longer needed. The time you lose indexing might be made
  39. up when you seek. You'll probably want to do some time trials to see
  40. if this approach improves speed over what you're already doing.
  41.  
  42. Hope this is of some use ...
  43.  
  44. Dean Burnfield
  45. The University of Texas Health Science Center at San Antonio
  46. Internet address: burnfield@uthscsa.edu
  47. Bitnet address:   burnfield@uthscsa
  48.