data-design question

[Bill]

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" <charles.hartman at conncoll.edu> 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
>>> 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
>> 
> 
> _______________________________________________
> 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
> 
> 

            |    |    |
           )_)  )_)  )_)
          )___))___))___)\
         )____)____)_____)\\
       _____|____|____|____\\\__
-------\                   /--------- 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