Basically, unless you are going to be cataloging thousands if pieces,
or are interested in strange queries of your data, you don't need a
relational database
On Aug 19, 2008, at 2:08 PM,n "David W. Fenton" <[EMAIL PROTECTED]
> wrote:
On 19 Aug 2008 at 7:35, Eric Dannewitz wrote:
A relational database probably is not the best thing to use for
doing this
sort of thing. Unless you want to mine your library for stuff, or
have
thousands and thousands of things in there
I'd say set up some sort of card system. That would the easiest
thing to do.
I would strongly disagree. The simplest example I could give of why
you'd want a relational structure is if you're searching for
repertory for a specific ensemble. If you use a flat cardfile-type
structure, you're forced to do some kind of tricky searching within a
single text field, where you have no idea how the instrumentation has
been entered (unless there is strict enforcement of how the
instruments are entered in terms of order and spelling. On the other
hand, the "spreadsheet" structure, where you have a column for each
instrument, is just as bad, since you have to search across multiple
columns.
With a table representing a many-to-many join between your music
table and your instruments table, you don't need to know the order of
the instruments nor do you need to word about variant spellings.
You'd query in just one place.
This is both more convenient to use and easier to set up a user
interface for others to use. And in the long run as your database
grows, it will also be vastly more efficient than the other methods.
That said, *something* is better than nothing for tracking your
library. A friend of mine recently started cataloging his record
collection by simply typing up a list in his word processor. This
gives him a searchable document where he can find things much more
easily than he could just scanning the shelves.
But he still doesn't have 100% certainty that he can find everything
that matches what he wants at a particular time, nor can he combine
criteria for searching. But it's certainly much better.
So, a flat file might be a decent place to start and then break out
data into relational tables as you find that the flat file causes
problems with providing needed functionality.
But one warning: cataloging music is more complicated than just about
any other data structure I've ever encountered. I would definitely
*not* start out trying to create a model that would be a "perfect"
data structure for cataloging music, because you may not need that
kind of precision structure.
The main point is that the way you structure your data will determine
how easily and reliably you can find particular pieces, unless you're
content to search on simple criteria like name and title. As soon as
you need something more complicated than that, it gets tough (and
even title searches can be problematic unless you enforce uniform
title entry somewhere along the line).
--
David W. Fenton http://dfenton.com
David Fenton Associates http://dfenton.com/DFA/
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
