On 13/03/2009, at 10:45 AM, Chris Anderson wrote:
It seems like most of these problems just go away if you
put all the data that needs to be edited transactionally into a single
document.
There is a tradeoff between document granularity and concurrency. A
simplified example - if you have user documents and you need to
transactionally move a token from one to the other, you can't solve
this problem by putting both users in one document, because the
operation is arbitrary, between any two users. Putting all the users
in one document kills concurrency.
There might be ways to restructure the data model to get around any
one problem (such as inversion of link directions or reifying the
token in my example), but in practice I've found that multiple
refactorings don't always co-operate, and the data model then affects
the UI because sometimes relationships need to model a user's
expectation, rather than what is convenient for the software.
I like your bank example - a useful answer to questions such as this
might be a catalogue of model transformations and alternatives.
Without impugning it's awesomeness, CouchDB will not be the right tool
for every job, and the cost of alignment with CouchDB semantics needs
to be considered as part of a design - that isn't perculiar to CouchDB.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies.
-- C. A. R. Hoare
