On Sat, 2005-11-05 at 10:55 -0800, ovonrein wrote: > pfarrell Wrote: > > The key problem is that any hierarchical structure fails for > > classical music. > You lost me with this one. I had thought that > Composer/Work/Artists/Movements > pretty much covers all bases. I am not too bothered mixing singers and > conductors in the Artists component.
Its all personal preference. You like Composer/Work/Artists/Movements where I would tend to prefer: /Genre/Composer/Artist/Work/Movements But I really don't want it to be hierarchical. Composer -> Work is fine, we all agree on that, but even something as simple as Genre is far too vague to be a major hierarchical divider. Some folks want to consider "Classical" as one genre (i.e. the NullSoft folks who brought you MP3 tags) yet anyone with a even modest sized classicial collection would distinguish between baroque, romantic, modern and post-modern. Sometimes the conductor matters, sometimes not, but the big conductors work with many of the major symphonies, you can't assume that Riccado Muti is always with Philly. > pfarrell Wrote: > > The alternative to hierarchical databases for the past 30 years has > > been a relational database. > Yes, and I have seen more chaos in relational databases than I ever saw > in hierarchical structures. Relational database design tends to require > more discipline than the average designer cares to muster. Hierarchical > databases usually impose it. Lets not go into theology here. I'll grant that the easy of use allows people who are clueless to design terrible relational schemas. The fact is that SlimServer starting with 6.0 has a relational database back end. We are using it, we can use it to do more. > pfarrell Wrote: > > > > The real solution is to use external data [...] in a relational > > database. A database with extensions so that there are clear and easy > > to use fields like conductor, soloists, accompanists, group, and > > performance-location for the recording and composer, title, movement, > > key, opus etc. for the music. > > > > You are beginning to lose me. I can only surmise that you are > proposing that my search should be able to traverse an arbritrary > number of attributes. Since we have a database, and a front end, you can use the predefined interface. Or, since it is all open source, we can build upon what is there and add a few columns. Back to theology, there is no requirement to expose the database, and proper code will simply ignore columns and tables that it doesn't know about. This is something that no hierarchy can handle. > And I am sure that you can make it work in your modern-day relational > database. Only SMOP. Way smaller now that all the heavy lifting has been done for us. We've got it, we might as well use it. -- Pat Farrell http://www.pfarrell.com _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
