Wouks, too many replies! I learned a lot by just reading. I will just reply to a few comments.
> To be honest, I think saying RDBMS and CouchDB are for different > solutions is just you guys being nice. I think that any application > would benefit from using the CouchDB model and only in very specific, > very demanding cases an RDBMS would be better. I can't think of any > examples though. Yes, see, this is what I started to believe as well. But this thread showed me that this idea is wrong. RDBMS are there and were written for a reason. CouchDB solves a different problem. It's not just a new storage layer that can be plugged into any existing (RDBMS) database abstraction layer and then "it just works". http://couchdb.apache.org/docs/intro.html "An object-oriented database. Or more specifically, meant to function as a seamless persistence layer for an OO programming language." > I'll help you: I think it would be easier to create a wiki with > CouchDB than with an RDBMS. It is possible in both but CouchDB just > makes it easier. I suppose we'd have to ask the http://couch.it guys > to know if that's true. Well. How does CouchDB make it easier? I think I'd be easier on some parts, and harder on other parts. As I said, I don't think (anymore) that CouchDB is supposed to replace a RDBMS, but instead solve a different problem. As soon as you need to scale horizontally, replication comes into play, think Wikipedia. Because of the eventual consistency, you might have many different versions of pages "live". Just think what happens when users start to edit and save old versions. This is a very interesting read http://www.facebook.com/note.php?note_id=23844338919 About cache invalidation. I just don't think that, as soon as you are forced to use replication, which is the whole point of CouchDB? Clouds? Scale horizontally? you can actually build a typical web application (wiki, forum, blog) that doesn't give the user a consistent experience. Now, if you build something like Antony Blakey (#9 in this thread), that seems like a really great idea on how to use CouchDB. > I know it would be fairly simple to have an "accounts" array field on a JSON > user-account document - that way no single "enities" account could be > changed by more than one write at the same time... seems rediculously simple > - but is there a case where this could fail? Well, isn't the standard example: Person A only has $500. 1 Check A's account: $500 2 Set A's account: $0 3 Check B's account: $1000 4 Set B's account: $1500 Now, if at any time between 1 and 2 or 3 and 4 you modify A's or B's account, you have lost. This is where it could fail? Assuming the four actions are not sent in the same request. Again. This is RDBMS thinking. In CouchDB, the balance should probably be a view. But there is still no way to enforce that you have enough money on your account before you can withdraw. Is there? Check Balance <- Other Instance Withdraws Withdraw > Things that CouchDB is better at: > The interweb. > Things that an RDBMS is better at: > Huge amounts of business logic. As in the Oracle install running your > favorite hospital. Think along the lines of 10's and 100's of > thousands of lines of app logic in the DB itself. You know, I am trying really hard, but these comments just contribute absolutely nothing to the discussion. > You can do that with Map/Reduce. > Create a view that gets all the comments and get them with limit=0, > there's your counter. No, you cannot. *Variable* criteria. A Map/Reduce is a fixed criteria. Also, a counter in the most abstract meaning. The only way to count something in CouchDB is to add every item to the database and then use a view. There is no +=. And there is no way to aggregate the count into a single key. Patrick, if you aren't trying, then don't. There are enough people who actually try.
