Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!midway!msuinfo!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.unix.programmer Subject: Re: ndbm won't cut it, what now? Summary: Only Message-ID: Date: 16 Nov 90 04:43:57 GMT References: <1990Nov11.111118.21856@cs.umn.edu> <2300@sixhub.UUCP> Sender: news@msuinfo.cl.msu.edu Organization: UW-Madison CS department Lines: 17 In-Reply-To: davidsen@sixhub.UUCP's message of 15 Nov 90 02:20:23 GMT 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. (For instance, being able to retrieve employees by either last name or SSN.) I don't know of any *dbm package which does this; it's not designed for it. Dbm/ndbm/gdbm works fine if you only have one key per record and don't need the records to be ordered; for slightly more complicated things, there's probably public-domain code floating around. For a real relational DB, unless one can use University INGRES, I suspect one would need to go the commercial route. Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+