Hello Patrick, I am writing down thoughts as they come. I would appreciate if you tried to follow. Yes, I realize storing comments inside the entry is a bad idea. I was following an introduction to CouchDB.
> Sure, use the view to get all comments and specify count=0. > You can get them in one query, just group comments by post_id in your map > reduce query. I don't think you understand my point. Yes, I know. Maybe you should re-read. You still need one lookup for every blog entry on a page. And there is no way you can ever store the comment count inside the blog entry. > startkey, endkey and limit. That sounds so great. But wait. LIMIT. I know that from SQL. It doesn't scale. Jumping to page 1234567 of ten million. Please, no. And you cannot, ever, group items based on a variable criteria. For example in batches of around one hundred. Which solves pagination. A view cannot provide that. But again, there is no way you can "manually" do it. > Anything! I challenge you. Build me a counter! No seriously. Pick one: GROUP BY, LIMIT, _rev to fake transactions. Uh. Oh. Hello SQL? You know something magical that allows you to avoid _rev. So please tell me. What exactly can I use CouchDB for that uses its strengths, and not weaknesses? I am honestly not trying to make a fool of anyone. The CouchDB book seems only to justify the design choices. The Wiki is completely unhelpful. Every time it gets interesting. http://wiki.apache.org/couchdb/How_to_implement_tagging It stops. That second article, that would certainly enlighten me. Yes, how, would you go about implementing that? I don't see how you can make it work but by using an awful lot of merging logic. Isn't that why you use a RDBMS in the first place? > It's already there. You're right, I missed that one. It's even more scary.
