incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Banking Recipe
Date Sun, 14 Nov 2010 23:14:42 GMT
"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> wrote:
> 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