Hi Ralf!
Thanks for your reply
Approach #3 is basically the one I am using, only that the post_id-
user_id document is the comment.
In your approach #3, wouldn't I have to do another trip to the
database for the blogpost there too? I can't really so a way to use
f.ex view collation to fetch both the relational document (comment)
and the blog post itself with a post_id-user_id document when the user
id isn't also specified in the blog post itself. Because then they
can't share a common key.
I hope this can somehow be solved with map/reduce later on.
Best regards
Sebastian
On Apr 12, 2008, at 8:53 PM, Ralf Nieuwenhuijsen wrote:
------=_Part_34546_33031881.1208044393514
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I'm no expert, but to me it seems you have some options
1) fetch all posts seperately. (that would be a nice cumaltive
roundtrip
penalty)
2) store comments in user-profile, instead of separately (annoying)
3) do the relational thing (sorry!), and store a unique document for
each
relation
Solution 3 would mean you put documents for each comment as such:
{
_id: "post_id-user-id"
postid: 9334,
userid: 3494,
type: "post-user-relationship"
}
By using post-id-user-id together as the user id you have no risk of
duplicating this information. If it doesn't exist you create the
document,
if it does exist you are just updating it to the exact same values.
With this separate relationship document you should be able to pull
trick #3
for both use-cases.
But it's getting really uncomfortable to use such a relational
approach
here.
Greetings,
Ralf
2008/4/12, Guby <[EMAIL PROTECTED]>:
Hi Christopher!
I read your post back when you posted it. It is an interesting read.
I'll try to explain my problem using your blog metaphor, maybe that
makes
it clearer.
First:
My first attempt was your approach number 1. Storing all the
comments in
the post itself. But I am already getting some 409 Conflicts in my
worker
processes (concurrency conflicts), and that is probably going to
increase
once I get users on my system, so that doesn't seem like a really
good
approach.
Approach #3 is good when you want to get a post and all its
associated
comments.
I, on the other hand, am trying to get all the posts that a certain
user
has commented on. If I wanted to use view collation the way you
describe I
would have to store the comment in the post or at least some token
that
indicates that a certain user has commented on a post, and then we
are back
to approach #1 which we are trying to avoid... or am I missing
something?
Best regards
Sebastian
On Apr 12, 2008, at 2:22 PM, Christopher Lenz wrote:
On 12.04.2008, at 18:13, Guby wrote:
My first attempt was to store the user ratings in the entry itself,
and then use a for loop in the view to map the entry to each user
ID, but to
store if the user has read the entry or not I would then have to
load the
whole entry with all its ratings change the value of one flag,
and then save
it all back. Seems like I would be loading an awful lot of
information and
wasting a lot of resources(?). Maybe I am trying to save computer
cycles at
the wrong place. What I ended up doing instead is more a
relational database
approach:
Now I have my entry document which only is the entry itself, and
then
user_entry documents that have references to the entry, stores
the users
rating and a flag wether or not it has been read and if the
rating passed
the users threshold or not. It works perfectly until I want to go
from a
list of user_entries to a list of entries. If I load a list of
user_entries
that have a certain rating I have to make a seperate call to the
database to
load each entry! That is why I tried creating a view that would
check the
user_entry and the return the qualified entries directly...
I you haven't read it already, I'd recommend looking at a blog
post of
mine that explores this stuff:
<http://www.cmlenz.net/archives/2007/10/couchdb-joins>
