"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 <luci...@ramalho.org> wrote: > On Sun, Nov 14, 2010 at 5:39 AM, Andy <andrh...@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 >
