Yes, that's what I asked for; a description of how those fields would
be handled in say, FileMaker, not in a flat file.
Very illuminating. Thank you Eric and both Davids for your input. I
think (was it David F who said this?) that music cataloguing is one
of the more complex tasks you can set up.
I notice now that the Excel spreadsheet catalogue I presently use has
some relational characteristics, though not as full-blown as an all-
out database.
For example, I have set up a table for ensemble type in Excel
(AppleWorks can do this, too.)
I also notice that once I have entered a composer's or publisher's
name, Excel wants to complete the name the next time I start to type
it. I realize that this is not the same as a proper database, but it
does help prevent misspelled variants of composers' names (like
Tchaikovski, or Tchaikovsky, or Chaikovski, or Tchaikowski, etc...!)
Christopher
On Aug 20, 2008, at 6:51 AM, dhbailey wrote:
But those are part of a relational database, not a flat file.
Anytime you have more than one table and they're linked so that
data from more than one table is displayed in the records onscreen,
you've got a relational database. Whether the data is stored in
different tables within a single database file or stored in totally
separate database files, makes no difference, they're both
relational databases.
Eric Dannewitz wrote:
Table for InstrumentsTable for Part (first, second, third) Table for
Composers and their Bio (assuming both those are unique)
Table for Style Of The Piece
Table for the Piece which would have pointers to Composers and
Style and to
a table which has
Parts (which has a pointer to Instruments and Parts)
That would be a start off the top of my head.
[snip]
--
David H. Bailey
[EMAIL PROTECTED]
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
