Hi everyone,

This is a resend of a mail I originally only sent to Jan.  He suggested I sent it on for others to comment on.  Feel free to let me know what you think!

Hey Jan,

a while ago when you were in Barcelona I mentioned the music program I
was working on and how I wanted to move it to couchdb.  You said I
should write down what I was trying to do and what my problems are, so
since I recently started hacking on it again (as a use case for paisley,
the twisted library for couchdb) and wrote some things down.

I'm attaching the rst that mentions the kinds of documents/ojects the
program deals with.  As you can imagine, I'm having trouble moving from
a normalized data model to a more couchdb-friendly one.  I added two
ideas for denormalizing that I think would be ok for me, but there are
some where I think it wouldn't make sense.

There is one big question I have that I don't know if it's possible at
all or not... but given how couchdb implements 'views' on the whole
document store that are created on the first request to that view and
then kept uptodate incrementally - why would it be so hard to use
couchdb as a normalized data store, and then create a view that
effectively denormalizes data doing more than the single join that the
'view for sql jockeys' chapter explains ?

Isn't the principle the same thing, and isn't couchdb simply only
lacking a way of expressing that kind of view ? Or am I missing
something fundamental here ?

Any feedback on my design ideas and how I want to model the data are
appreciated.  Let me know if you have questions; in particular it's
important to treat Track as the central object, with Slices into
AudioFiles just being the on-disk representation of that track.

Thanks
Thomas


-- 
morgen wordt het beter beter voor iedereen
dan krijg ik de strop
en jij wat je verdiende
--
GStreamer - bringing multimedia to your desktop
http://gstreamer.freedesktop.org/