couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Orr <nicholas....@zxgen.net>
Subject Re: Banking Recipe
Date Sun, 14 Nov 2010 23:26:35 GMT
On Mon, Nov 15, 2010 at 10:14 AM, Robert Newson <robert.newson@gmail.com>wrote:

> "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.


True single documents being updated/created are atomic.
However if you want to update/create/delete more than one and all of them
need to be done as a whole (transaction), then CouchDB isn't going to work
as well (can be done an the application level though why bother, use a
suitable tool for the task)  as a traditional RDBMS

:)


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message