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 (even with the suggested autocompletion) and the erroneous data ends up alphabetically before the correct data, all further entries that are made via autocomplete will end up with the incorrect version. Secondly, it's still storing duplicate data. What if you discover after you've entered all your data that you've misspelled the composer's name, or that you find out what the composer's middle initial is and want to include it. With a composer table, you make the change in the composer table once, and it automatically flows through to all records connected to that composer. If you store the data in every single record and want to change it, you have to run updates on the data to fix it. In a multi-user scenario (granted, this is not one), that can lead to all sorts of problems. > A small database of like 1000 pieces can easily be done flat file, It can be, but it is not advisable to do so, particularly when there is a library template already available that is properly normalized, relationally speaking. > and > really doesn't warrant a huge relational structure, especially when the > person who is setting it up probably does not do that sort of thing in the > first place (or else, why would they have been asking). This is the argument that all those clients who've paid me 1000s of dollars made when they implemented their flat solutions to their problems. > Your points on 14 years of DB yada yada doesn't mean anything in this > case...... You can ignore the voice of experience if you want, but it's really easy with a flat structure to completely screw up your data and make it impossible to trusts the results of your searches. > and it is going past what the original question asker wanted to > do. They want to keep track of their music and who has what. This can be > done, in the easiest way, on index cards or something, Index cards lack all sorts of features that a normalized database can offer. Enter the data once in a database and you can search it on any data in the database. An index card can only be sorted in one place, so if you want multiple searching capability, you have to create cross-reference cards. A literal cardfile is much worse than a flat Excel spreadsheet. And "easy" is often not "best." Nor in the long run, does the initial "easy" method turn up to be either easy or reliable. > or a flat file > database like Bento or Filemaker or something. Those are not flat file databases. Bento is built on top of Filemaker and has relational capabilities. Filemaker has the same thing, and templates that solve the problem of planning the relational structure and designing the user interface to edit and search the database. > That is totally what the > original poster should aim for. So you say. > 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. I know of no relational database of any kind that will allow such a deletion without asking the user to confirm the deletion. And whether or not it deletes the related records is going to differ from database to database, depending on how the structure has been set up. In the vast majority of cases, that kind of "cascade delete" is best turned off, and in the case of composer/work should *definitely* be turned off, so that it's impossible to delete a composer record that has music attached to it. So, yes, of course you can do it wrong. 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 W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
