data-design question

Charles Hartman charles.hartman at conncoll.edu
Sat Sep 24 18:55:23 EDT 2005


Thanks. But Dreamcard won't do that, right? That's what I've got.

I'm not aware of compilations of the kind of data out there that I'd  
need. (iTunes, by the way, is completely ignorant dumb about  
sidemen.) I can imagine a version of the program that queries Google  
to find out who each listed player is . . . but not in this lifetime.

So does this feel unbuildable within Rev? I suppose I could go build  
it in Python . . . but we don't yet have a way to put a Rev front end  
on a Python program, as far as I know.

Charles


On Sep 24, 2005, at 3:05 PM, Dan Shafer wrote:

> 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
>
>
> _______________________________________________
> 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
>




More information about the use-livecode mailing list