From: Bill_P_Pearce@cup.portal.com
Newsgroups: rec.music.classical
Subject: Re: records-database
Date: Wed,  2 Sep 92 22:02:08 PDT
Organization: The Portal System (TM)
  <CB.92Aug31153656@tamarack13.timbuk>
  <1992Aug31.222510.18481@fid.morgan.com> <34831@cbmvax.commodore.com>

 In article <CB.92Aug31122022@tamarack13.timbuk> Chris Brewster
replied to my original posting about database programs for
cataloging a record collection, and a number of interesting
comments from others have followed.  Chris make a very good point
about my original posting: I mentioned that one could also use a
flat file database manager, but then I went on to describe the
advantages of a relational database.  In fact, I did not really make
clear why I had chosen to use a relational database manager like
Alpha Four.  My choice was for some of the very reasons that have
been described, particularly the ability to deal with multiple
databases at the same time.

   What I have done is to have my primary database contain eight
fields: Work, Composer, Performers, Label, Format (i.e. cd, lp or
cassette), Record Number (not to be confused with what the
database manager calls "record number", that is the consecutive
numbers it assigns to each data "record" you enter into the
database), Shelf Location, and what I called "Serial Number."  This
is all the information I felt I needed to have in my primary
database.  Then I have five subsidiary databases containing lists
of works, composers, performers, record label and format.  The
beauty of the relational database manager, as has been pointed
out by a number of people, is that you don't have to keep retyping
composer, performer, etc.  When they have once been typed into
the respective subsidiary databases, you can call them up with a
keystroke or two and have them automatically inserted into the
appropriate field in the primary database.  

   The way Alpha Four does this is that when you get to the point
of entering   data into a particular field in the primary database,
for example Composer, a pop-up list of composers appears from the
subsidiary database that is linked to the Composer field and you
simply highlight the correct one and enter it.  The composer then
appears automatically in the Composer field in the primary
database.  Moving to the next field, Performer, results in a pop-up
list from the Performer database appearing, etc.  I certainly
agree that it saves a lot of typing time.  The field that is least
amenable to this treatment is Work, since there are so many
possibilities.  All I have is a short list with "Symphony No.",
"Concerto No.", etc.  When I am entering a work that is not of a
type contained in the subsidiary database ("Aida", for example), I
can just type it in, overriding the pop-up list choices.

   On the other hand, you can accomplish a lot with a flat file
database, as Margaret suggests, but it does not seem as
convenient to me as what I have described above.  I do actually
use Alpha Four in that manner sometimes.  For example, I was
recently entering data records for Schubert songs, of which I
have a lot of lp's by Fischer-Dieskau.  The simplest way to do it,
after I had created the first data record, was to use the feature
that will create the next record by automatically coping the
previous record.  Then all I had to do was to change the name of
the song (and the record label and number and accompanist
occasionally).  This does not require the relational database's
capability to interact among multiple databases.  This approach is
not useful, however, if you are entering a Mozart symphony, for
example, and the previous record in your database is something
entirely different, so I think it is preferable to have the
relational database capability.

   I mentioned a field I called "Serial Number" above.  I have used
this because I ran into a problem with indexing and sorting.  Alpha
Four creates what it calls a "browse table", which is a sort of
summary of the database, in whatever format and including data
from whatever fields you choose.  I expect to use it to print a
listing of my recordings from time to time (not on my dot matrix
printer at home - it would take forever!).  I set up a browse table,
with sorting primarily on composer, then on work and then on
performer, all alphabetically.  "Work" is a "character" field,
however, as opposed to a "numeric" field, and Alpha Four does not
recognize that the Shostakovich Quartet No. 15, for example,
should come after Quartet No. 6, since it doesn't understand
numeric values contained within a character field.  It would
instead place Quartet No. 15 after Quartet No. 1 and before No. 2,
which is not what I wanted.  

  I solved this problem with a sort of "brute force" method by
including an entry in the primary database in what I called a
"serial number" field for each work which has a number, i.e. Quartet
No. 4, Symphony No. 3, Concerto No. 4, etc.  These three data
records would have serial numbers 4, 3 and 4, respectively.  Then
I set up the sorting index to sort on composer, work, serial
number, and performer, in that order, which solved the problem. 
Most of the data records don't need a serial number, since they
aren't dealing with numbered works. (I assume the program assigns
a 0 value to the Serial No. field in that case.)  It does not seem
like a very elegant solution to the problem, though, and maybe
somebody who knows more about these things than I do can suggest
a better way to do it.

  In any case, any method is vastly preferable to what I used to do
until a year or two ago: type 3x5 index cards on an electric
typewriter.  Originally I even put on each card every work that
was contained on a given lp, and then typed a separate card
showing each work first, i.e. going through what mathematicians
would call a cyclic permutation, so there would be a card in the
file under each work! (I did decide some years ago that it was
unnecessary for each card to show every work on the record, so
I changed to showing only one work on each index card.)  My interim
solution was to create my 3x5 index cards on my word processor
and print them out, which worked fine, but now I am abandoning the
cards.  As someone aptly pointed out, the use of the technology
always seems to lag behnd the development of the technology. 


       Bill Pearce