If you thought that a hash was a good data structure that might work for our problem of having to maintain a last good guess database, then you were partially correct. For example, the statement
$last_good{$name} = time;%last_good that has the
name for a key. Over time, this would seem to give us a database indicating the most recent
time the secret word was guessed properly for each of the users who had invoked the program.
But, the only problem is that the hash doesn't have an existence between invocations of the program. Each time the program is invoked, a new hash is formed. So at most, we create a one-element hash and then immediately lose it when the program exits.
Now, there is a function in Perl that maps a hash out to a disk file (actually a pair of
disk files). The function is dbmopen, the disk files are known as a
DBM, and it's used like this:
dbmopen (%last_good,"lastdb",0666) || die "can't dbmopen lastdb: $!";
$last_good{$name} = time;
dbmclose (%last_good) || die "can't dbmclose lastdb: $!";
The first statement performs the mapping, using the disk filenames of
lastdb.dir and lastdb.pag (these names are the normal
names for a DBM called lastdb).
The second statement shows that we use this mapped hash just like a normal hash. However, creating or updating an element of the hash automatically updates the disk files that form the DBM. And, when the hash is later accessed, the values within the hash come directly from the disk image. This gives the hash a life beyond the current invocation of the program - a persistence of its own.
The third statement disconnects the hash from the DBM, much like a file
close operation.
While the statements that we have seen so far maintain the database (and even create it the first time it is used), we haven't yet seen any way of examining the information that might get put into the database. What programming element(s) do you suppose is(are) required to complete this task? Could we format a report from the database?
See you next lesson!