You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Andy <an...@hotmail.com> on 2010/11/14 08:39:24 UTC
Banking Recipe
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.
Re: Banking Recipe
Posted by Sebastian Cohnen <se...@googlemail.com>.
I'm personally not sure wether the banking example is good one or not, but: summing up transactions isn't that bad, since the result is saved in the views b-tree. after first computation you get the result very fast.
On 14.11.2010, at 08:39, Andy 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.
Re: Banking Recipe
Posted by Nicholas Orr <ni...@zxgen.net>.
On Mon, Nov 15, 2010 at 10:14 AM, Robert Newson <ro...@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 <lu...@ramalho.org>
> wrote:
> > On Sun, Nov 14, 2010 at 5:39 AM, Andy <an...@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
> >
>
Re: Banking Recipe
Posted by Mike Fedyk <mf...@mikefedyk.com>.
On Sun, Nov 14, 2010 at 3:42 PM, Luciano Ramalho <lu...@ramalho.org> wrote:
> On Sun, Nov 14, 2010 at 9:14 PM, Robert Newson <ro...@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.
>
> Sure, that is exactly the point of the banking recipe, and I believe
> Andy -- the original poster -- got it, but he felt it the model was
> unsuitable to the kinds of transactional apps he had in mind, and
> perhaps he is right.
>
> If one can model every transaction as a single document POST, great.
> Not all applications can be bent to work that way.
>
I agree. It just seems that the part that the OP didn't get was the
point of views and how to use them. You don't want to store summary
data in documents (like counts), that is what views are great for.
Otherwise you'd have cascading updates, to update one count and then
update another count and so on. Let couchdb work for you. :)
Re: Banking Recipe
Posted by Luciano Ramalho <lu...@ramalho.org>.
On Sun, Nov 14, 2010 at 9:14 PM, Robert Newson <ro...@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.
Sure, that is exactly the point of the banking recipe, and I believe
Andy -- the original poster -- got it, but he felt it the model was
unsuitable to the kinds of transactional apps he had in mind, and
perhaps he is right.
If one can model every transaction as a single document POST, great.
Not all applications can be bent to work that way.
--
Luciano Ramalho
programador repentista || stand-up programmer
Twitter: @luciano
Re: Banking Recipe
Posted by Robert Newson <ro...@gmail.com>.
"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 <lu...@ramalho.org> wrote:
> On Sun, Nov 14, 2010 at 5:39 AM, Andy <an...@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
>
Re: Banking Recipe
Posted by Luciano Ramalho <lu...@ramalho.org>.
On Sun, Nov 14, 2010 at 5:39 AM, Andy <an...@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