data-design question

[Charles Hartman]

Many years ago I wrote a jazz-record-collection database program in C  
-- so many years ago that memory problems raised by sparse arrays of  
unpredictable size led me into baroque designs involving pointers-to- 
pointers-to-pointers . . . It occurs to me that Rev would make a nice  
front-end for this both easy and pretty. But I'm wondering what the  
best approach to the data structure(s) would be.

Assume that the basic record (in the database sense) is Album -- so  
the basic design is one card per Album. Each Album includes a list of  
Tunes (besides Artist/Group and Label/Date/EtcData). Each Tune is  
associated with one or more Writers, and also with a list of Players,  
each of whom is associated with an Instrument. So we've got at least  
four fundamental types of data lists -- player, instrument, tune- 
title, writer -- and some items that combine fundamental items in  
many-to-one relation.

The program would be useful (at least to me) only if it were possible  
to search it on any of those criteria. (Show me every Album including  
a Tune by Matt Dennis on which Steve Swallow is playing bass.)  
Obviously it's necessary to be able to add to each of the fundamental  
data lists -- which suggests combox-box menus -- and it would be  
important to have a series of defaults (same players for all tunes on  
an album, for example) to encourage data-entry.

Any suggestions about the best approach to the internals of this? I'm  
not clear whether, for example, custom properties are up to the  
demands of what's essentially a relational database . . .

Thanks for any help in thinking about this.

Charles Hartman