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 & neueweise < [EMAIL PROTECTED]> 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 results of that belief. >> > > i would v-e-r-y s-t-r-o-n-g-l-y second these comments. i had to clean up > a DB a few years ago for the canadian electroacoustic community (who i also > work for) that had a flat structure (i think the earliest versions of FM > didn't allow for relations to be built across files [now this is done with > tables within the same file]), and so 14 years of poor DB understanding and > use combined with no attempts to correct the situation as the DB grew cost > the organization a not insignificant amount of money to fix. > > an important point, perhaps, is that while some corporation can afford to > hire people to fix problem X or Y, smaller arts orgs do not typically have > access to the kinds of budgets required for DB management. and a > poorly-designed or insufficient DB will not only cost you $ years later to > fix, everyone who tries to work with it will spend 5-10% (or more!!!) time > doing data entry -- or searches -- than should be needed. > > the main problem with flat structures (non-relational) is that repeated > data eventually ends up with variants: person names are spelt wrong in one > of the numerous records, so searching for the composer omits the > wrongly-spelled data; in our case, biographical notes appeared on every > record with the contact's name, and so there were several bios for the same > composer in some cases, meaning i had to spend time just trying to figure > out which one was in fact right and most up to date. with a relational > structure, unique information (composer bio, birthdate, contact info) > appears only once and any updates are immediately visible in all records > related to that type of information. > > ah, also helpful is to have auto-entry fields date_created and > date_modified. > > > > _______________________________________________ > Finale mailing list > [email protected] > http://lists.shsu.edu/mailman/listinfo/finale > _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
