ndbm won't cut it, what now?

[John R. Levine]

In article <RANG.90Nov15214357 at nexus.cs.wisc.edu> rang at cs.wisc.edu (Anton Rang) writes:
>In article <2300 at sixhub.UUCP> davidsen at sixhub.UUCP (Wm E. Davidsen Jr) writes:
>>  The secret to having multiple keys in a dbm database is to use the
>>first byte as the key type. It's that easy, and works very nicely thanks.
>
>  Actually, I thought the original poster meant 'multiple keys' in the
>sense of one record having several access paths to it.

You can fake it by making one key the primary key and storing the actual data
in its record.  The secondary keys point to the primary key.  To keep sizes
down you might want to make the primary key something small and boring like a
three or four byte serial number. 

Logically each key type is in a separate file, but you can combine them into
one big dbm file using the prefix byte trick.  It's gross, but no grosser
than what real data bases do every day.

You may need to keep copies of the secondary keys in the primary record if
you want to be able to delete the record or change the primary key.  A
perfectly workable alternative is to delete the primary key record when you
delete the record, be prepared for secondary keys to be left dangling, and
delete them in a batch run when you scan the file and pick out the dead wood.

If you do anything like this, the first thing you should do is a consistency
checker that reports secondary keys with no primary keys and (if it's an
error) vice versa.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl at iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Typically supercomputers use a single microprocessor." -Boston Globe