Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!gatech!ncar!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.perl
Subject: Re: need advice - writing a database system
Message-ID: <5223:May823:32:1191@kramden.acf.nyu.edu>
Date: 8 May 91 23:32:11 GMT
References: <1991May3.093532.19393@ccu.umanitoba.ca> <1991May03.143716.827@convex.com> <1991May3.165954.303@jpl-devvax.jpl.nasa.gov>
Organization: IR
Lines: 15

In article <1991May3.165954.303@jpl-devvax.jpl.nasa.gov> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
> Other than that, I agree with everything Tom said.

I don't. Every fixed-length field in a user database should be stored in
a flat file indexed by uid. You can trivially keep a linked list of
available uids if allocating a uid has to be fast. Real name, home
directory, and so on can be stored in fixed-length fields with an
exception pointer for the occasional really long entry. This will be
much smaller, faster, and easier to use than a hashed database.

Hashing is pointless when the things being hashed are already numbers in
a small range. For mapping from username back to uid, you probably want
a hash table, but you shouldn't store records that way.

---Dan