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 original posters needs.
Could we define our terms for the non-experts here? What the heck is
a"flat database," and why do you say (in another message) that FMP is
one when David says it is something else?
John
A flat file database is basically a computer version of the
old-fashioned index-card records found in an old-fashioned
library card-catalog. All the data about an individual item
is included in a single record in a single database file.
A relational database setup is where several different
tables or database files hold different sorts of data and
those different tables/database files are linked to each
other so the information from one shows up on another.
In the current discussion, the flat-file model would require
each record to have all the data that is desired to be recorded.
For example: Title, Composer Last Name, Composer First
Name, Composer Middle Initial, Composer Years, Instrumental
Ensemble, Instrumentation, Arranger Last Name, Arranger
First Name, Arranger Middle Initial, Publisher, Publisher
address, Publisher City, Publisher State, Publisher Zip
Code, Publisher Country, Sales Agent, [and any other data
you want to be able to find later on].
So if you have 20 works by Beethoven, in a flat-file
database you need to reenter all that composer and publisher
information over and over again for each work. With a
relational database, you would enter all that composer
information in the Composer table, and then each time you
enter a new work by Beethoven, all that data would
automatically be filled in without duplicating all that
data. Same for the publisher information. Once set up, it
makes entry of further items easier since you would enter
the composer last name and all the other information would
appear in the appropriate field.
Relational databases are wonderful for sales situations,
where a store would have a database of customers, a database
of inventory and a database of manufacturers. To generate
an invoice, they enter the customer ID (could be a number or
a last name), they enter a part number (or upc code), they
enter the quantity, and everything else is filled in and the
invoice is completed in seconds, as opposed to having to
look up everything manually and re-entering the part
description, the customer address and other information and
the prices.
They don't have to be complex, and they don't require huge
amounts of data to make the effort worthwhile.
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. But even membership lists
can benefit from relational database usage, where the zip
code is all that's necessary to fill in the city and state,
but that's such a small benefit that for most membership
lists it doesn't add that much benefit.
--
David H. Bailey
[EMAIL PROTECTED]
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
