Dan Zimmerman wrote about cataloging his collection:

>They contain 446 different compositions but some of the entries are
>"aggregate" composition.  For example each WTC book or Brahms Op.119
>count as one "aggregate" composition in my data base (OTOH each of the
>Shostakovich string quartets count as 1 entry, each Schubert Lieder is 1)
>I feel a bit ashamed cutting a corner here but I don't have the energy to
>type 48 preludes and fugues.  I decided that I will split an "aggregate"
>entry if one day I buy a CD in which only a part of the "aggregate"
>composition is played.  I wonder how other people in the list who mantain
>a data base dealt with this issue?

Here's how I handle this in my ClassiCat cataloging program (apologies for
the techno-speak, but this is a technical question):

* There are separate tables for recordings, compositions and movements
* Each movement of a composition has an ordinal number associated with it
  that is unique for that composition (it is never displayed in the
  application)
* The "recording selections" table associates the recording with a
  composition but also has a column for the movement number. If this
  number is a non-zero value, then the "selection" is a "movement" in
  an aggregate composition.

A more normalized solution would create yet another associative table, this
one between the recording selection and movements.  I rejected this as I
was already doing enough table joins already.  ;-)

The associative tables allow the user to type in the composition one time
after which they can define them as recording selections by selecting from
pre-populated lists.  They create the need for more programming to handle
the relationships, but that's what software is for - to do work for us.

Tim Dickinson
[log in to unmask]
http://www.tdware.com