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 just personal preference. you propose
> Composer/Work/Artists/Movements

but I'd probably go with 

> 
> pfarrell Wrote: 
> > 
> > Extra directories can be setup by you now. But that won't
> > do much, as it is hierarchical thinking that is the root problem.
> > 
> > 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.
> 
> Oh and - granted - there is the *odd* problem that could indeed not be
> elegantly represented in hierarchical form ;)
> 
> pfarrell Wrote: 
> > 
> > For me, the answer to [tagging] is again, use anything that is
> > consistent within your library, but don't lose much sleep over it. The
> > [...] reality is that the limits of internal tags become painfully
> > clear with classical. So just tag the files basically and move on.
> > 
> 
> I am with you on that once since from what I can make out, the Slim
> player interface only allows me to retrieve by file tree structure. 
> Tags come in later, when it comes to building the playlist.
> 
> 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.
> 
> The Slim player interface will adapt, since it will simply follow these
> branches.
> 
> This would work.
> 
> And I am sure that you can make it work in your modern-day relational
> database.  Only SMOP.  As a small aside, I had thought that you would
> have found a hierarchical database a much more natural choise - they
> adapt too, you know ... :)
> 
> 
-- 
Pat Farrell
http://www.pfarrell.com


_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to