couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From william cinnebar <merz.onl...@gmail.com>
Subject stale document references
Date Wed, 05 Aug 2009 14:11:21 GMT
I have some data I want to store.
Initially i was using common rdbms and querying with sql because this method
of storing data is popular and very well supported.
Then i found that xml is a better way to explain/map/store the data.
I have since found that json is better still and overcomes a lot of the
problems that occur using xml.

I like couchdb for json documents, js querying and the erlang.
Iv read through much of the couchdb documentation.

It seems from what iv read that it is better to minimise the document size
due to the way couchdb incrementally performs updates to the data.
It also seems there are methods to efficiently collate views of related
documents and query the data.

I have come across the assertion that documents should be self contained but
what exactly is meant by this?

Perhaps I have missed some important information?

Isnt normal/denormal relative to any particular use case of a document?
A document that is in a normalised state for one use may be in a
denormalised state for another use without any change to the document.
What would be achieved by duplicating data for each use case?

At what point is a document rendered denormal in couchdb terms and isnt it
just a matter of perspective?

How do couchdb document references go stale?
Is the replication process unstable?
Does couchdb forget stuff for some reason that is not documented (or that i
have missed?)

The couchapp/sofa model does not appear to be relevant to the model i am
working with.
There seems to be no reason in the core documentation why the model I am
working with could not be implemented using couchdb.

Also I apologise id like to request further clarity: what exactly is meant
by the term 'standalone application' where couchapp/sofa is concerned?

cheers
will

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message