This is the strings database package.

BSD fortune(1) includes a utility, strfile(8), which is intended to generate
the indexes for the fortune files.  fortune(1) is an orphan that lots of
different strangers have abused, but the concept behind strfile is actually
quite interesting: it breaks with the database paradigm most commonly found
in use.  In that paradigm, all records are the same size, with the same
fields.  A different paradigm (though one originally not intended for
writing databases) may be found in the MARC database structure commonly used
by librarians: the underlying concept of that database is that the record
must be parsed to discover both its size and its contents.  strfile(8) was a
very primitive implementation of a similar idea.

Apart from fortune(1), what is the use of a strings database?  In the
strfile(8) form, not much, unless one wished to define each line of a record
("string") as containing particular information.  Doing so, though, breaks
the underlying paradigm somewhat; it forces every record to be of a given
number of lines.  Adding fields to the strfile concept adds to its
flexibility.

In this more flexible form, containing fields (which may or may not appear
in any given record), a strings database can have a great many uses. 
Address books are a good example; a primitive implementation is included
here.  Bibliographic records are another possibility (it is freely admitted
that this format is not as powerful as MARC, but it isn't intended to be,
either); the included RFC database should show how close the fit is with the
strdb implementation in that regard.  Another possibility would be a means
of taking notes, complete with attributions or whatever other fields are
wanted.  The lack of a predetermined length (except that record size is
limited, on most machines, to 64 Kb, which is intended to avoid memory
faults more than anything else) means that free-format text can still be
effectively indexed and searched.

(Note: the above programs are mostly gone, now.  XML happened, you know.)

Apart from fortune(1), the other common net.use of a random database (a
database from which something may be drawn at random) is to vary the
contents of the .signature file.  An example application is included.

And of course, there is fortune.  Given advances in display technology, a
fortune tied to 80x25 tty is pretty limited.  The included implementation is
intended to fulfill several goals: to provide equal quality output on the
standard 80x25 tty, full capability of reading any previous format strfile
file (which includes singly and doubly delimited records (% vs. %%)),
improved maintainability of the databases, and improved display quality on a
variety of output devices.

These four applications do not exhaust the possibilities, or at least I much
doubt that they do.

Now, what is this *not* useful for?  It is a *strings* database, mind. 
That's what it's intended to handle, and although I can think of a number of
ways to extend it so that it could have "data types" based on field
delimiters, permitting it to store and handle numbers in a compact form,
that would break one of the guiding principles, which is to keep the data in
as easily-editable a format as possible--as text files, in fact.  The only
unusual character that should ever appear in a strings database data file is
the backspace character, which is a clever hack that indicates that a record
has been deleted (but not yet purged).  Likewise, the indexes are supposed
to be built on the platform where they are used, so if the code is portable,
so should be the indexes (that is, the indexes are not portable, but if the
utilities are, then indexes can be built on any platform that the utilities
can be built on and the data files copied to, which should be most).

So, if you want something that handles numbers gracefully, don't look here. 
Where numbers are actually being used as sequential identifiers, it *is*
possible to use this database (part numbers come to mind as a classic
example), but if there's any need to perform arithmetic operations on data
contained in the strings file, the strings db toolkit is going to be
disappointing.

Guiding Principles:
1) Provide a complete toolkit for generation and maintenance of indexes into
simply-formatted (text-only) data files.
2) Maintain some form of compatibility with the format of existing data
files, particularly those for fortune(1) in all its guises.  In other words,
maximize data portability.
3) Let the user decide.  Everything, where possible.
4) Provide some primitive applications to demonstrate the possibilities of
this form of data storage/retrieval, since it seems less common than
fixed-format databases.
5) Make the code portable.  For applications, support as many output device
types as feasible, ideally by using a method that the user may extend
without too steep a learning curve; all applications should provide a common
back end (if possible based on the core utilities) and a customizable and
effective front end.

The only one of these principles that I'll grade myself on is number 2,
which I think I get an 'A' on.  Piaterka na vtorom.  Yay for me.  I know
that I haven't achieved what I wanted on some other items.
