:54 PM
To: finale@shsu.edu
Subject: Re: [Finale] TAN: building a database for a music library
Fenton, shut the fuck up guy.
Other people suggested Excel, or even file cards. It worked well for them.
Why not the original poster? So I chime in and say I think it is overkill
to
have a relational
On Aug 24, 2008, at 9:57 AM, Margaret whitby wrote:
My apologies, I'm somewhat out of date about FMPro being cross
platform now. What I was really trying to say though was that in
relatively small groups of people---orchestras or any other
associations---most members have Excel on their
Hi Johannes,
Also a few other things I forgot to mention in my last post:
If you have Appleworks on your mac right now, try using the simple
database within that (there are various small database set ups in the
templates folder) you never know, it may prove to be enough for your
needs but
Oh dear, I have opened a can of worms.
To be honest, we have dropped the whole idea for the moment, as it
really isn't worth the trouble right now.
Not that this will stop this discussion I guess.
Johannes
--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
I use AppleWorks to catalogue my quintet's music library. We have
fields for Number, Title, Composer, Arranger and when the piece was
last performed.. We have 500 pieces of music. So far, when I need
to look up a piece, I can do it easily.
Question: is AppleWorks Database Flat or
Eric Dannewitz wrote:
My position does have merit. I worked as a DBA (Database Administrator) for
two years in a startup that was eventually sold off to the University Of
Phoenix. I dealt with hundreds of thousands of tests that came in flat file
and we had to design aggregated table structures
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
Christopher Smith wrote:
On Aug 19, 2008, at 8:09 PM, David W. Fenton wrote:
But a flat file approach is guaranteed to produce far more problems
in the long run than are possible with a relational structure, unless
that, too, has been improperly designed.
David,
You seem to have a lot of
Margaret whitby wrote:
I would strongly support FileMaker Pro, it does a wonderful job and I
use it for all our orchestra info.
Re the borrowing information---it might be better to have a separate
file for that as the number of fields required in one file would perhaps
be rather cumbersome.
John Howell wrote:
At 4:21 PM -0700 8/19/08, Eric Dannewitz wrote:
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the
Lawrence David Eden wrote:
I use AppleWorks to catalogue my quintet's music library. We have
fields for Number, Title, Composer, Arranger and when the piece was last
performed.. We have 500 pieces of music. So far, when I need to look
up a piece, I can do it easily.
Question: is
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
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
I have a FileMaker db that I access routinely that I can open on both
mac and PC. This confused me as well. Bento is their only Mac-only
product.
On Aug 20, 2008, at 5:52 AM, dhbailey wrote:
Margaret whitby wrote:
I would strongly support FileMaker Pro, it does a wonderful job and
I use
I think someone mentioned this analogy but, think of a flat file
database as a single box of index cards. You can sort them, you can
search through them, but there's a lot of duplicated information. This
is fine if you only have a few things to worry about. To use Johannes'
example, say
On 19 Aug 2008 at 23:09, John Howell wrote:
Could we define our terms for the non-experts here? What the heck is
aflat database,
A flat database is a table with columns and rows, not related to
any other table. An Excel spreadsheet, or a table in Microsoft Word
would be a flat database.
On 20 Aug 2008 at 7:08, dhbailey wrote:
Flat-file databases are wonderful for things like membership
lists and other lists where the data from one record to the
next is almost never duplicated.
Membership databases are another one of those applications that seems
very straightforward, but
On 20 Aug 2008 at 10:05, Christopher Smith wrote:
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
Membership databases are another one of those applications that
seems very straightforward, but when you get into it, can be quite
complex.
yes, definitely. the CEC has person and institutional memberships, as
well as memberships that are assigned to a position within the
institution. the
At 1:03 PM -0400 8/20/08, David W. Fenton wrote:
Membership databases are another one of those applications that seems
very straightforward, but when you get into it, can be quite complex.
I've built many of them over the years, and each has its own set of
problems, according to the needs of
On 20 Aug 2008 at 15:16, John Howell wrote:
Last Fall I started using Entourage to pull data from my Excel
Gradesheet and generate/send individualized grade reports to the
students in my largest class. It ACTS like a database, but is it
really? (I hasten to say that *I* did not set this
Johannes,
We have all our primary and secondary source material (microfilms,
books, new and old editions, etc.) in several File Maker Pro
databases (running on Macs), which can be searched for as many
criteria as you choose to enter originally (composer, performing
forces, performance
Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on
a Mac? I want something which is easy to maintain and where I can see
how many string parts we have, perhaps also who
i am using filemaker, some of the terms may be specific to it...
if you spend the time in the beginning you will save loads of time
rebuilding / restructuring the thing later. keep it simple, but each
type of data should have its own field. do not build multiple DBs,
keep all the
--- dhbailey [EMAIL PROTECTED]
wrote:
I can't recommend a program for Mac, but it can be
done with
either a spreadsheet or a database. Either program
should
give you the ability to look at the data in
different ways.
Microsoft Office is available for Mac - I'm using
Excel for my
duh. obviously the contact info goes in the composer table.
in the works table, for example:
composition_title
composed_in
composer_ID
fl_scored
ob_scored
cl_scored
[...]
fl_parts
ob_parts
cl_parts
address
city
province
country
in the composer table:
family_name (avoid using last_name, can
I highly recommend Bento--It's made by the file maker folks, it's
inexpensive, and really easy to use.
http://www.filemaker.com/products/bento/overview.html
On Aug 19, 2008, at 12:38 AM, Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing
music
You know, it would be wiser to aggregate the data even more.
Rather than having the works table have fl_scored, cl_scored, etc, have a
scored_id and another table that that links to.
scored
id, instrument_id
instruments
id, name
Sorry, did Oracle DBA for 2 years for a startup right out of
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.
On Tue, Aug 19, 2008 at 3:02
Access is not available for the MAC unless you run VMware or Parallels.
Steve
8/19/08 8:02 AM, Lora Crighton [EMAIL PROTECTED] wrote:
--- dhbailey [EMAIL PROTECTED]
wrote:
I can't recommend a program for Mac, but it can be
done with
either a spreadsheet or a database. Either
I'd like to add my vote for FileMaker Pro. I'm a choral director and find it
to be very flexible, easy to use and able to do just about anything I can
dream up.
One of the keys is what several have already mentioned about planning what
info you need and how you're going to be using and entering
Agreed on all points. One thing, though: It would certainly be
possible to have fields for who has each part checked out, but
remember that every datum has to be entered and that this will take
your librarian quite a while. There are times when a simple paper
signout sheet is still
I'd like to add one more thought to the plan well before
starting idea --
Once you have it planned out, enter only 5 or 10 works, with
all the data as you have it planned out, then run some
typical queries on it to see if it will give you the
information you want.
There's nothing worse
On 19 Aug 2008 at 7:38, Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on
a Mac? I want something which is easy to maintain and where I can see
how many string parts we
On 19 Aug 2008 at 9:02, Lora Crighton wrote:
Microsoft Office is available for Mac - I'm using
Excel for my church choir library. The spreadsheet
does have limited database functions,
Excel is really terrible for database needs. It is great for what
it's intended for, but if you really need
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
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
On 19 Aug 2008 at 14:20, Eric Dannewitz wrote:
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
This is what many people believe. I make a large portion of my income
fixing the
Eric Dannewitz wrote:
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
But if you also want to be able to put together information
on the composers, you'd have the composer
On 19 Aug 2008 at 18:04, dhbailey wrote:
Eric Dannewitz wrote:
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
But if you also want to be able to put together information
on
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
This is what many people believe. I make a large
portion of my income fixing the results of that
belief.
i would v-e-r-y
I think Filemaker actually will try to complete the field as you type it.
So, if you are Typing Amadeus it will complete it before you do.
A small database of like 1000 pieces can easily be done flat file, and
really doesn't warrant a huge relational structure, especially when the
person who is
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters needs.
On Tue, Aug 19, 2008 at 3:28 PM, shirling
Eric Dannewitz wrote:
[snip]
On the flip side, a relational database is very easily messed up. You delete
the foreign key to the composers table that was linking song titles to their
composers. Not easy at all to fix. And a lot of people who have no database
experience can very easily do this.
Point is that the original poster is not a database worker. And has no plans
on having tens of thousands of things in the database. Therefore, using a
flat file database, like Bento, or even index cards, would be totally fine
to use. They really don't need to learn how to set up and manage a
I think Filemaker actually will try to complete the field as you
type it. So, if you are Typing Amadeus it will complete it before
you do.
nope. but value lists come close to this.
A small database of like 1000 pieces can easily be done flat file,
and really doesn't warrant a huge
On 19 Aug 2008 at 16:18, Eric Dannewitz wrote:
I think Filemaker actually will try to complete the field as you type it.
So, if you are Typing Amadeus it will complete it before you do.
But that's not by any means the same thing as enforcing correct
entry. For instance, if somebody mis-types
On 19 Aug 2008 at 16:21, Eric Dannewitz wrote:
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters
Geeze, go back and read the ORIGINAL POST
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on a
Mac? I want something which is easy to maintain and where I can see how many
string parts we have, perhaps
I give up. Fine. Get the guy a relational database. Hell, get him an Oracle
one. Might as well get the best right? Who knows how many times he'll need
to run queries on how many string parts a Mozart concerts from XYZ edition
have..
On Tue, Aug 19, 2008 at 5:09 PM, David W. Fenton
[EMAIL
On 19 Aug 2008 at 16:41, Eric Dannewitz wrote:
Point is that the original poster is not a database worker. And has no plans
on having tens of thousands of things in the database. c
Show me where in Johannes' original post where he says any of these
things:
On 19 Aug 2008 at 7:38, Johannes
On 20 Aug 2008 at 2:04, shirling neueweise wrote:
why the reactionary response to relational DB structures?
Eric always has to disagree with any position I'm advocating.
[only half joking]
--
David W. Fentonhttp://dfenton.com
David Fenton Associates
My position does have merit. I worked as a DBA (Database Administrator) for
two years in a startup that was eventually sold off to the University Of
Phoenix. I dealt with hundreds of thousands of tests that came in flat file
and we had to design aggregated table structures for them. All in Oracle.
On 19 Aug 2008 at 17:14, Eric Dannewitz wrote:
Geeze, go back and read the ORIGINAL POST
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on a
Mac? I want something which is easy to maintain and
On 19 Aug 2008 at 17:16, Eric Dannewitz wrote:
I give up. Fine. Get the guy a relational database. Hell, get him an Oracle
one. Might as well get the best right? Who knows how many times he'll need
to run queries on how many string parts a Mozart concerts from XYZ edition
have..
It
On Aug 19, 2008, at 8:09 PM, David W. Fenton wrote:
But a flat file approach is guaranteed to produce far more problems
in the long run than are possible with a relational structure, unless
that, too, has been improperly designed.
David,
You seem to have a lot of experience here. Assuming
On 19 Aug 2008 at 17:21, Eric Dannewitz wrote:
I have the experience.
It's too bad your posts to this list on this subject do not exhibit
any evidence of that experience.
It is totally overkill setting up a huge relational thing
Nobody suggested a huge relational thing -- that's a straw
Fine David. You are right. As always. You obviously know every thing. As
usual. And you personally attack. Yet again.
Moron.
On Tue, Aug 19, 2008 at 5:25 PM, David W. Fenton
[EMAIL PROTECTED]wrote:
On 19 Aug 2008 at 17:16, Eric Dannewitz wrote:
I give up. Fine. Get the guy a relational
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
Fenton, shut the fuck up guy.
Other people suggested Excel, or even file cards. It worked well for them.
Why not the original poster? So I chime in and say I think it is overkill to
have a relational database. Then you go off on a tangent again. As usual.
Oh, and start belittling people. As usual.
On 19 Aug 2008 at 20:35, Christopher Smith wrote:
On Aug 19, 2008, at 8:09 PM, David W. Fenton wrote:
But a flat file approach is guaranteed to produce far more problems
in the long run than are possible with a relational structure, unless
that, too, has been improperly designed.
You
On 19 Aug 2008 at 21:18, Margaret whitby wrote:
I would strongly support FileMaker Pro, it does a wonderful job and I
use it for all our orchestra info.
Re the borrowing information---it might be better to have a separate
file for that as the number of fields required in one file would
Fine David. You are right.
ah, so i am too i guess, cool. i was starting to wonder... whew.
now i can sleep peacefully.
And you personally attack. Yet again.
Moron.
fighting fire with fire?
___
Finale mailing list
Finale@shsu.edu
Yes, snuggle up with your comfy whatever.
Fire with Fire is the only way a Fenton works..
On Tue, Aug 19, 2008 at 6:27 PM, shirling neueweise
[EMAIL PROTECTED] wrote:
Fine David. You are right.
ah, so i am too i guess, cool. i was starting to wonder... whew. now i can
sleep
At 4:21 PM -0700 8/19/08, Eric Dannewitz wrote:
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters
FileMaker can do both if you wanted. Flat database would be like index
cards. Relational database is more like a spider web, where there are little
parts that are related to multiple things.
On Tue, Aug 19, 2008 at 8:09 PM, John Howell [EMAIL PROTECTED] wrote:
At 4:21 PM -0700 8/19/08, Eric
66 matches
Mail list logo
