data-design question

[Phil Davis]

Hi Charles -

In the late 90's I wrote what was essentially a relational database in 
Metacard (the precursor to Revolution), using custom properties, to 
manage data in a medical information application. The data consisted of 
about 5000 HTML files that took up about 15mb of space. The indexes 
(stacks) used to support searches etc took up another 16mb or so.

Bottom line: It can be done, but your code must manage index creation 
and maintenance as well as all search and save processes. It can be 
interesting, but it may not be for everyone.

Phil Davis



Charles Hartman wrote:
> 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