data-design question

[Dan Shafer]

Charles....

To me, this screams out for a relational database model. I wouldn't  
even begin to attempt it with custom properties; too many levels of  
interconnectedness.

I'd build the data management stack of this app as a one-card stack  
using SQL queries for the functionality. And with Rev's world-class  
Internet connectivity operations, tying it into existing jazz and  
musician sites and even sources of album covers and in-depth  
information of other kinds should be feasible. Could produce a very  
nice, even commercially viable, app.


On Sep 24, 2005, at 11:34 AM, 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
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Information Product Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
 From http://www.shafermediastore.com/tech_main.html