incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Petty <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 14:51:18 GMT
Mr. Donut, Jan,Damien, others in the thread,

Just want to say thank you.

I'm being completely serious here.  I have to agree that in the beginning I
sensed hostility from Mr. Donut - but he was hitting on many questions I
knew there were answers for and after a few minutes could conceptualise -
but never had at the tip of my tongue to give to the other RDBMS guys in my
office when they rightfully grill me about using CouchDB for the next gen.
production environment.

Could this thread be added to the wiki - with only minor editing for length
- maybe as "a RDBMS vs couch 'Discussion' ?"  or something similar?"...

Mr. Donut - please continue.....

And Damien - I might be wrong but I believe the consistency Donut was
referring to the was maybe changing the type of data in a field on the back
end midway through the app lifecycle - or maybe through a bug in the
application.  Or conversly adding a field - which also would then be handled
through the business layer.  I would guess this would include refining a
view to include it if it needed to be searched on - and then correcting the
business layer to accomodate for either the new view - or the new key in the
I was thinking this was a benefit but it did take a some redefinition of the
scope of a database for me to understand from the getgo. Also, it seems to
simplify the schema into truely being part of the business logic layer of an
applicaiton.  If the data needs an application to get to the database -
finally we can enforce that data integrity in only one place - but, Donut if
this isn't accurate, please reframe.

 (and I see Jan has answered in a similar and yet much more eloquent way
while I was typing this...)

-- Adam

On Mon, Feb 9, 2009 at 9:27 AM, Mister Donut <> wrote:

> > I'm suspecting here
> > that you assume that views are created on demand, based on user-input.
> No, I understand.
> > Totally generic object behaviour abstractions
> > in SQL need something like 8 tables, there's no way this flies :)
> No, I was talking about the "Stuffing" implementation. All it does is
> adding a schema-free field to an existing database? I just don't see
> what it has anything to do with CouchDB?
> > How? (Assuming you have a use-case in mind, can you explain that?)
> Again, about the "Stuffing". It doesn't handle the lack of immediate
> consistency. This is just what I seem to observe here. Everyone
> praises the schema-free and JSON, but noone keeps the *eventual*
> consistency in mind?
> > Again, can you wrap that into a concrete example, I don't quite get what
> > that mini-RDBMS is and how your understanding of replication ties
> > into that :)
> You have to deal with the *eventual* consistency in your applications
> don't you? And isn't that incredibly hard and expensive? I mean just
> think about the end user, when he might put something in CouchDB, but
> not immediatly see it, in fact, it might be gone for a very long time.
> What interactive application can work with that?
> > I have another contract about to start for a server app where all the
> > data is maintained on the client's desktop, previewed with full
> > functionality, and then replicated to an EC2 instance. This can be
> > done with traditional databases, but it's trivial with CouchDB,
> Well, this is trivial with all databases? Just import and export. It's
> just copying a file. Now imagine two users working on the data. Yes,
> you have replication built in, so no data gets lost. But you still
> need to figure out all the merging? Hum.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message