I'll jump right in. > CouchDB won't allow you to "jump to page X", but if you look at > e.g. Google, it doesn't work either. [...] > But surrogate keys are considered harmful and I'd say (but that > really depends on the application), not very helpful.
I guess I was assuming that CouchDB, due to its different nature, has a sophisticated solution for this. But apparently pagination is a problem that is really hard to solve. > Can you elaborate on that? I don't quote get the "or duplicate data, > basically anything that needs to be the same as something else" bit. Well. Let's say you have a list of documents. You want to store some information about the newest document in a separate key (instead of a view, which might be slow? if you have too many). That isn't possible. Or let's say you have documents, and categories. And many, many, many of them. Again, the view to show the latest document might be too slow, so you want to save that information in a separate key. Not possible. > A couple of things you can do with CouchDB replication (again, not saying, > that you can't do some of those with an RDBMS but it is getting harder > the further you move down the list): [...] Thank you for that list. I think, and like many other users, considering what I have read in blogs, seem to expect something else from CouchDB. I am not so sure where this is coming from. Check the Ruby thing a few mails down. How exactly is that implementation going to work without immediate consistency? Everyone seems to be going on about it being schema free, but you can just add a "param" field to any database and transparently (un)serialize and there you have it, schema-free. If you actually have a few nodes (with that implementation), it will break big, big time. I think, possibly, with the "Cloud Hype", that I got into believing, that it will "just work". With anything that you throw at it. Like what Amazon SimpleDB tells you it would. Yes, Key/Value pairs are incredibly easy. MapReduce is amazing and intriguing. But handling the replication, won't it be so difficult that you end up with a Quasi-Mini-RDBMS anyway? Now I got far away from my original questions, but I guess that happens often in discussions. Basically, now: "Is it possible to handle the replication in such a way that you don't end up with a Mini-RDBMS anyway in the end?" I would just, really really really, like to see an example that goes beyond schema-free. That handles replication. I think that would show where CouchDB shines, and where you'd fail with a RDBMS. And, CouchDB isn't magical glue to make pagination work, either.
