Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!uunet!convex!usenet
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.lang.perl
Subject: Re: need advice - writing a database system
Keywords: database, dbm
Message-ID: <1991May03.143716.827@convex.com>
Date: 3 May 91 14:37:16 GMT
References: <1991May3.093532.19393@ccu.umanitoba.ca>
Sender: usenet@convex.com (news access account)
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Software Development, Richardson, TX
Lines: 66
Nntp-Posting-Host: pixel.convex.com

From the keyboard of rahard@eeserv.ee.umanitoba.ca (Budi Rahardjo):
:
:Hi there,
:I am in the process of writing a userid database for our computer networks.
:
:I need suggestions :
:
:1. Would you use a flat file or dbm file for the database ?

Dbm file.  You're talking a lot of records here.

:2. Would you slurp the whole file ? (considering the number of fields,
:   and the size of the database)

No -- too expensive.

:3. If I use dbm file (with assoc. array)
:   - I'd like to index it with different fields (ie, userid, lastname, uid).
:     How do I do this ? (Use different dbm files ?)

I don't think you'd want to duplicate the records, although what you might 
do is to use an indirection scheme where primary lookups are keyed on userid
and for the rest you first map the secondary key to the primary key, as in

    $record = $database{$uid_to_login{$uid}};


:   - When I update a record, I want to save it right away.
:     Do I have to close the dbm file (dbmclose) and re-open it again ?

No.

:     ie. Is there away I can update the dbm file without closing it ?

You can use the reset operator if you're careful.  It is documented 
to flush the database cache.  As of 3.018, its primary effect is
to generate a coredump, but as of 4.003, it appears to work just fine.

:4. Access to the database by more than one persons at the same time
:   is desireable.
:   How would you lock the database when you perform critical operations,
:   like add a new entry, or updating a record ? (Use perl lock ? or
:   just create a file, say  "lock.db", then remove it after you're done ?)

If you want the granularity of the locking to be at the level of the
entire database, this will be easy.  If you want it at a record level, it
will probably not be.  Because of the way dbm works, you can't just lock a
particular region of the file.

You mentioned a networked Sun environment.  If you're using NFS, then you
*must* use the lockdaemon, meaning you'd better use fcntl()s.

If you're not using NFS, and the locks are maintained by one process,
simpler schemes may suffice.

:5. Security
:   How would you implement security ?

Depends on your level of paranoia.  Privileged ports and program may 
be enough if you're trusting of all superusers on your network.  Otherwise
you might want to use secure RPC.

--tom
--
Tom Christiansen		tchrist@convex.com	convex!tchrist
		"So much mail, so little time."