On Mon, Nov 15, 2010 at 10:14 AM, Robert Newson <[email protected]>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 <[email protected]> > wrote: > > On Sun, Nov 14, 2010 at 5:39 AM, Andy <[email protected]> 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 > > >
