Why do you think you can't build that in Dreamcard? MySQL access is included and the plug-n for SQLite is inexpensive.
On 9/24/05 6:55 PM, "Charles Hartman" <[EMAIL PROTECTED]> wrote: > 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 >>> [email protected] >>> 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 >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-revolution >> > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > > | | | )_) )_) )_) )___))___))___)\ )____)____)_____)\\ _____|____|____|____\\\__ -------\ /--------- http://www.bluewatermaritime.com ^^^^^ ^^^^^^^^^^^^^^^^^^^^^ ^^^^ ^^^^ ^^^ ^^ ^^^^ ^^^ 24 hour cell: (787) 378-6190 fax: (787) 809-8426 Blue Water Maritime P.O. Box 91 Puerto Real, PR 00740 _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
