On 9 Feb 2009, at 15:51, Adam Petty wrote:
Mr. Donut, Jan,Damien, others in the thread,
Just want to say thank you.
Heh, thanks.
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?"...
Feel free to collect a summary put it into the wiki :)
Cheers
Jan
--
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
view.
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 <[email protected]>
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.
