On Aug 19, 2008, at 6:45 PM, shirling & neueweise wrote:
again: no one has denied these methods can work. several people have pointed out the benefits of relational DB over a flat structure, which you seem to disagree with. fine, but just because you disagree doesn't mean you're right, which is what you are trying to (rather forcefully) convince us of by making a "huge... thing" out of relational DB and essentially claiming they are inherently complex and therefore not suitable for anyone except DB management types (with one obvious exception of course). i.e. you haven't really explained why flat files are better than relational in this case, except with unsubstantiated claims about relational NOT being the "best" thing for johannes... who should make that decision for himself and is probably just avoiding this futile discussion and shaking his head in amazement... following all of this is more complex of a thing that actually learning about and building a relational DB.
You can argue the "right" thing all night. I'm not going to argue that a relational database isn't a good thing. It is. For huge amounts of data. But his requirements didn't suggest this at all, so, even though in theory it would be best to setup a rather elaborate relational database with probably 7 tables linking to each other (parts, instruments, composer name/bio, style, piece, checkouts (holding the date, piece, part, people who check out what), people). Why bother when you could just have it flat file, and just write a note at the bottom who check what out when? Simple, easy, works.
Heck, why not just generate bar codes for each part and get a bar code reader, and require all members to have cards and do it that way? I mean, Fenton's probably already typing a thesis paper about it right now........
_______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
