From: lampson@tellabs.com (Dave Lampson)
Subject: Re: records-database
Organization: Tellabs, Inc., IL
Date: Tue, 1 Sep 1992 23:26:52 GMT

In article <1992Aug31.190143.6161@Princeton.EDU> mikulska@crux.Princeton.EDU (Margaret Mikulska) writes:
>As opposed to our regular fact-ladden scheduled programming, now it's 
>clearly time for personal, biased opinions.
>
>I think that it's really an overkill to use a heavy-duty commercial
>database.  I don't think that data about recordings are complex, and in
>my greatly biased opinion a flat ascii file plus a few UNIX tools - grep,
>awk, and sort should do for most purposes - is entirely adequate for
>retrieving any kind of information needed.  And all these tools are free
>once you have UNIX.

Indeed, as with any application of technology, using the *appropriate* 
technology is the important thing.  A 33MHz '486 is overkill to balance 
your checkbook, but try tackling a 100,000 cell spreadsheet with hand 
calculator and not get lost.  Likewise, try planting petunias with a 
backhoe...

That said, I think Margaret's approach is perfectly sound for a small
collection.  Data entry with a small collection usually wouldn't take
much longer than learning how to use a powerful relational database.
But for my case (3200+ CDs), a flat file DB would be very close to useless,
and I would have to spend my entire life maintaining it as I added to the 
collection.

Now that I have my database designed (admittedly a non-trivial task, 
especially since I had no model upon which to base my efforts), I actually
save time and disc space over entering the same data in a flat file DB.
For example, by keeping a master file of composer names, I never have to
worry about inconsistent spellings (Rachmaninoff or Rachmaninov?) - the
database takes care of that for me - but as important as consistency, I
save keystrokes.  For the composer field, I only have to enter enough of
the composers name to make it unique (in this case "rach") and the program 
automatically fills in the rest.  This same process applies for labels, 
directors, ensembles, performers, instruments, and anything else I might
want to standardize on.

Bottom Line:  If you have a small collection and only track minimal
information, then just about any method that you feel comfortable with
is going to be effective (Hey, you can always import data into a DB!). 
But, if you have a large collection and/or want to be able to track a
variety of data, go for the relational database.  They aren't nearly as
scary as they first appear, and can actually save you tons of time and
disk space and keep your data internally consistent.


>The really hard part is typing in the entries.

As mentioned above, a relational database actually *saves* many, many
keystrokes and makes the job of entering the data a lot easier.

>A randomly typing monkey
>is of little use, unfortunately.

Unless you are a JohnCageian, then this could be considered music 
(just *listen* to it as music, it will change your life!).  (:-)

Hey, what do you want?  A definition of music that includes John Cage but 
excludes a monkey at a typewriter?  Come on, I'd never be able to get it
past Roger! (:-)

-- 

Dave
lampson@tellabs.com

For detailed lists of Recommended Classical CDs, Basic Repertoire and Buying
Guide access cs.uwp.edu (131.210.1.4) by anonymous FTP, or email me for info.

Contribute to the rec.music.classical biography project!  Email me your bio!

Newsgroups: rec.music.classical