Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.216.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=CLJHEimF/9tWrlOgi/ueT9y5PpvLpDNPpYhmJSKq64P4NuC8XE5LBeiGOpCM/h3Vv9
         d90qad9W6iOjHNG4MHv9upult0RVHRNmAIem47AmvIEeyVGzH3HI69gLYGUVawpWMyYy
         A7yrYqVnTvjEnyG00pg5sJM3a5u9QOWldMPrM=
MIME-Version: 1.0
In-Reply-To: <AANLkTikpHnzgjfeVOmhWA91wcVPuAS=pwH=H8xsTRZn_@mail.gmail.com>
References: <SNT135-w20A20948EBD82FFE239C54D9350@phx.gbl>
	<AANLkTikpHnzgjfeVOmhWA91wcVPuAS=pwH=H8xsTRZn_@mail.gmail.com>
Date: Sun, 14 Nov 2010 23:14:42 +0000
Message-ID: <AANLkTik2JbCJBumVrgAz+_eRPHQFbQ65MjxOX8mp_O67@mail.gmail.com>
Subject: Re: Banking Recipe
From: Robert Newson <robert.newson@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

"If you really need transactions in the classical, RDBMS sense, where
you need to update a bunch of related records in one atomic operation,
then CouchDB is not for you."

I think that's a little overstated. Instead, realize that updates to a
document are atomic, and therefore you should model your transactions
as documents.

B.

On Sun, Nov 14, 2010 at 10:53 PM, Luciano Ramalho <luciano@ramalho.org> wro=
te:
> On Sun, Nov 14, 2010 at 5:39 AM, Andy <andrhahn@hotmail.com> wrote:
>>
>> Im well versed in Java/Hibernate/RDBMS. =A0Im trying to get my head arou=
nd how NoSQL does not use transactions.
>> I read the Banking Recipe which didn't really do the job: http://guide.c=
ouchdb.org/draft/recipes.html
>> So if I wanted to write an online banking app, I would have say a millio=
n Transaction Documents, and to find a persons balance I would need to sum =
all transactions? =A0There must be a better way.
>
> Hi, Andy.
>
> If you really need transactions in the classical, RDBMS sense, where
> you need to update a bunch of related records in one atomic operation,
> then CouchDB is not for you.
>
> If you are an expert backhoe operator, and your main job is digging
> trenches, don't switch to a forklift or you will be disappointed.
>
> CouchDB is document database. It shines and makes you life as
> programmer much easier if your application has a document centered
> model. Here is an example.
>
> I've been involved in project to create a repository for clinical
> trial records (CTR). A CTR is a large record, with several embedded
> sub-records, such as researcher data, sponsor data, patient
> recruitment parameters and so on. In our cases, many of the fields are
> multilingual, for example, procedure descriptions must be given in
> English and the language(s) of the country(ies) where the clinical
> trial is recruiting. Once published, a CTR must never be changed or
> deleted. If updated, the previous version must be kept intact and a
> permanent link to it is embedded in the new version.
>
> This is a mess to implement securely using a relational database. One
> conceptual record becomes dozens of records spread over dozens of
> tables. Normalization helps with "update anomalies" but in this case
> we don't want a related record to be updated behind our backs, losing
> track of the previous state of the CTR. In many cases here, updating
> *is* the anomaly, so we don't want it to be easy or fast, we need to
> control every bit of information in the CTR as one whole.
>
> A document oriented database is perfect for a job like this, because I
> can structure and manage the whole CTR as one document. Keeping past
> versions frozen is a snap. CouchDB is just the right tool for a job
> like this.
>
> A forklift sucks at digging, but if you need to move crates around,
> nothing beats it.
>
> --
> Luciano Ramalho
> programador repentista || stand-up programmer
> Twitter: @luciano
>