Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!spdcc!iecc!johnl From: johnl@iecc.cambridge.ma.us (John R. Levine) Newsgroups: comp.unix.programmer Subject: Re: ndbm won't cut it, what now? Message-ID: <1990Nov16.145542.22326@iecc.cambridge.ma.us> Date: 16 Nov 90 14:55:42 GMT References: <1990Nov11.111118.21856@cs.umn.edu> <2300@sixhub.UUCP> Reply-To: johnl@iecc.cambridge.ma.us (John R. Levine) Organization: I.E.C.C., Cambridge MA 02238 Lines: 31 In article rang@cs.wisc.edu (Anton Rang) writes: >In article <2300@sixhub.UUCP> davidsen@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@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl "Typically supercomputers use a single microprocessor." -Boston Globe