From: steve@fid.morgan.com (Steve Apter)
Subject: Re: records-database
Organization: Morgan Stanley & Co., New York, NY
Date: Mon, 31 Aug 1992 20:23:42 GMT

In article <CB.92Aug31122022@tamarack13.timbuk> cb@tamarack13.timbuk (Chris Brewster) writes:
>Bill Pearce writes:
>
>   ... One could use a simpler flat field database manager for this
>   purpose too.  As with most such [relational] programs, Alpha Four 
>   allows you to set up whatver kind of format you want ...
>
>Bill, I think your second statement above (and its implications) is the
>best argument against the first statement.  Data about recordings is
>actually pretty complex and difficult to manage effectively.  Although I
>haven't bit the bullet and done the work yet, I've thought about how I
>want to approach it.  My main aim for a recordings database would be to
>eliminate redundant typing while allowing complete flexibility in how
>the data is retrieved.  I think this aim requires a fully relational
>database (such as Alpha 4, Personal RBase and not many others).  
>
>In other words I would have separate tables of recordings (by number),
>performers, composers, works, etc.  Each table item would be typed only
>once.  A table item would point to items in other tables.  The table of
>recordings would need to occupy a central position in this structure.
>With this structure, you could inquire about all the pieces played by a
>certain performer, all the recordings of composer X played by performer
>Y, etc.  Any less flexibility would greatly reduce my motivation to
>create a recordings database.
>
>Maybe we should hear from Dave Lampson on how *he* structures his data
>(or anyone else with such a system already operating).
>
>Chris Brewster
>cb@cray.com

I keep databases of books and records primarily for insurance purposes,
and only secondarily to provide information about recordings to people
who want to know if something exists, what label it's on, &c.  Only
very occasionally do I need to fashion the complex "queries" which
would justify a full-blown relational system.  As Chris says, I'm
mainly interested in reducing typing on entry.

I keep a simple ascii text file, where each entry has the form

	composer/works/artists/label/#_disks

E.g.,

	Schutz/Symphonia Sacrae/Schreier/Capriccio/5

Hyphen acts as a delimiter (with an especially simple-minded rule 
for expanding an entry into multiple output records -- see below.)  
I depend on the search-for/cut-and-paste capabilities of my favorite
text-editor (sam, occasionally emacs) to minimize typing on entry
(e.g. look for "Beethoven/Symphony 7", copy the line, edit.)

Every once in a while I run a routine to parse the text file and
produce five one-to-one text files.  These in turn can be sorted,
selected, and glued together into a text file which can be printed
or displayed.  But most of the time I just work with the raw file.

The advantage of this approach is that you never leave the world
of ascii, the raw data stays readable, and you never run over the
bounds of any crucial internal database variable.  Moreover, if
you feel like adding another "field" (like catalog number), just
add "/" and start typing.

A line such as

	Beethoven-Schumann/Symphony 7-Symphony 2/Celibidache/Hunt

gets expanded to

	Beethoven	Symphony 7	Celidibache	Hunt	1
	Schumann	Symphony 2	Celidibache	Hunt	0

(0, since I don't want to double-count this disk.)  Nothing fancy,
but perfectly adequate for my needs.  (In retrospect, I should have
included catalog #, but I'm too lazy to enter all those numbers.)

In short, commercial "dbmss" are probably overkill for personal
record-keeping of this sort, and only a modicum of programming
skill is required to write converters, sorters, printers, what
have you to your own spec.  But keep the data ascii is my advice.

Now what would really be nice is to have the Schwann or Stevenson
catalog in machine-form.