Joel Ewing's post makes several important points. Hashing would certainly reduce the size of the key space to be searched, making your search scheme a little less important.
Another possibility that you should consider is the use of a binary-search tree (BST). Even without AVL balancing or the like it should be possible to search such a BST using about 10 comparison operations per search. If I were doing it I would use a 40-byte node block (NB) comprised of four pointers (one to the left subtree, one to the right subtree, one to a key block, and one to the information you need) and eight bytes for modal switches. This scheme makes NBs reusable, and it separates the management of the BST from that of the heap you will need for records. (I assume that since records vary significantly in size they can also grow.) Another design issue you need to consider very carefully is that of backup. The BST could be traversed readily (in, say, ascending key sequence), making both incremental and full backup operations easy to perform. Finally, the anxieties about the use of [virtual] storage above the bar that have been expressed here are, in my view, overstated. If you manage that storage at all well its use should be unproblematic. People whose primary job is storage management will of course be concerned, properly, about your the possibility that your system could malfunction in ways that made enormous, unanticipated demands on limited real storage; and for this reason you should involve them actively and from the beginning in what you are doing. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
