incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Ramalho <luci...@ramalho.org>
Subject Re: Banking Recipe
Date Sun, 14 Nov 2010 22:53:33 GMT
On Sun, Nov 14, 2010 at 5:39 AM, Andy <andrhahn@hotmail.com> wrote:
>
> Im well versed in Java/Hibernate/RDBMS.  Im trying to get my head around how NoSQL does
not use transactions.
> I read the Banking Recipe which didn't really do the job: http://guide.couchdb.org/draft/recipes.html
> So if I wanted to write an online banking app, I would have say a million Transaction
Documents, and to find a persons balance I would need to sum all transactions?  There 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

Mime
View raw message