Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 199.193.200.196 as permitted sender)
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1877.7\))
Subject: Re: Would this be a sane use case for couchdb?
From: Jens Alfke <jens@couchbase.com>
In-Reply-To: 
 <CAFf7Ch1tecvYAc+d71e=HE5B6OW0EwZhm8tv=D=VqYs-deTaOw@mail.gmail.com>
Date: Wed, 9 Apr 2014 09:23:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <4D6E8FCA-A2F4-49D2-A489-8DC7A87DC9C2@couchbase.com>
References: 
 <CAFf7Ch1tecvYAc+d71e=HE5B6OW0EwZhm8tv=D=VqYs-deTaOw@mail.gmail.com>
To: <user@couchdb.apache.org>


On Apr 8, 2014, at 11:45 AM, Der Engel <engelster@gmail.com> wrote:

> The webapp is going to be a invoicing software for certain niche,  so =
I
> guess I probably need a DB were transactions are reliable and data
> integrity is very good.

CouchDB doesn=92t offer transactions, at least not in a traditional =
sense. While updating a document is atomic, updating multiple documents =
is not; essentially each document update is its own little transaction. =
(Even if you use the _bulk_docs command.)

If you can accept that, data integrity is great. The append-only file =
format is almost immune to corruption, and databases are very easy to =
back up efficiently (via replication.) The MVCC feature prevents you =
from accidentally overwriting the wrong version of a document, or from =
doing a read-edit-write cycle that smashes someone else=92s intervening =
write.

The lack of transactions may seem bad, but often it just requires =
thinking different[ly] about your data. In a document database you can =
aggressively *de*normalize by storing multiple small data items inside a =
single document, instead of in separate tables =97 a canonical example =
is an address card doc that stores arrays of phone numbers and emails. =
Such a document will always be internally consistent. It=92s also =
possible to create a pseudo transaction as a document that contains a =
list of the IDs other documents and revisions that are collectively =
consistent.

Anyway, if you do get to clustering with any database, you=92ll probably =
find that you have to lower your standards about transactions anyway. =
Clustered databases mostly respond to the constraints imposed by the CAP =
Theorem by relaxing Consistency. Those that don=92t (by using shared =
locks) will instead suffer from lowered Availability or =
Partition-tolerance.

=97Jens=