data-design question

[Stephen Barncard]

Producer? Mixer? Mastering Engineer?

Better go MySQL or other SQL. Many Lynux based ISPs will include it 
with your web goodies, and far easier than dealing with setting up a 
server. Easy to set up relations, etc.

sqb

>Charles --
>
>I see you've already received a lot of advice about implementation tools, so
>instead I'll focus on metadata.  Maybe the metadata will influence your
>choice of tools.
>
>There seem to be several categories of relevant metadata.  As I see it, here
>are at least some of them:
>     album data
>     track data
>     composition data
>     recording data
>     performance data
>     acquisition data
>     importation data
>     reference data
>
>For some details about these categories, see the following notes.
>
>To me, the richness of the metadata suggests there may be significant value
>in further collaboration, such as in the Dublin Core Metadata Initiative.
>Whether you want to engage in a core metadata initiative or not, your
>perceptions of your needs will probably evolve significantly as you proceed.
>So I suggest an important factor in selecting tools be your ease of changing
>your metadata.
>
>-- Dick
>
>----------------------------------------------------------------------------
>In the following notes,
>     {} indicates multiplicity -- example: {genre}
>     = indicates decomposition -- example: group = {person}
>     -- indicates a comment -- example: this comment
>----------------------------------------------------------------------------
>album data =
>     title
>     label -- examples: Capitol, RCA
>     series  -- families of albums on the same label
>     release date
>     {genre}
>     medium -- examples: vinyl, CD
>     copyright
>     track data
>    
>track data =
>     album
>     track number
>     composition data -- a composition may appear on more than one album
>     recording data -- a recording may appear on more than one album
>
>composition data =
>     title
>     music by {person}
>     lyrics by {person}
>     composition date
>     {genre}
>     variations on composition
>     medley of {composition}
>     copyright
>
>recording data =
>     composition
>     recording date
>     {genre}
>     studio
>     recording engineer
>
>performance data =
>     recording
>     artist
>     instrument -- examples: guitar, voice
>     performance category -- examples: solo, lead, backup
>
>acquisition data =
>     album
>         -- an album may have been acquired more than once because
>         -- of damage to the media
>     track
>         -- individual tracks from the same album may have different
>         -- acquisition dates and sources
>     source -- examples: iTunes, Wherehouse
>     acquisition date
>
>importation data =
>     recording
>     bit rate
>     encoding scheme
>     importing date
>
>reference data =
>     persons
>     groups -- group = {person}
>     genres
>     instruments
>     performance categories
>     media
>     labels
>     series
>     studios
>     sources
>     encoding schemes
>     bit rates
>----------------------------------------------------------------------------
>On 9/24/05 11:34 AM, "Charles Hartman" <charles.hartman at conncoll.edu> 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
>
>
>_______________________________________________
>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