couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mister Donut <>
Subject Re: The Blog
Date Tue, 10 Feb 2009 04:50:46 GMT
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".

"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 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

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

> 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.

View raw message