What you propose is to have a document initially and any other future changes as new document parts (of the original document), those reference to the previous document parts until the initially document. Is this correct?
But it has a problem to construct the document to the last state because must read all documents changes and apply all to the original document. A view could do it? What do you think? 2011/11/2 Alexander Shorin <[email protected]> > Hi, > > "Each document represents some completed state(event - it just was as > it is and history couldn't be changes) and doesn't affected from > external data" - start from this point(; To reduce document size you > may include related document _id and all vital fields that shouldn't > be changed in time for it. > > Another approach is keeping references both to _id and _rev of related > document, but all would be broken if someone runs database compaction > (also this method doesn't works for views). > > -- > ,,,^..^,,, > > > > On Wed, Nov 2, 2011 at 2:20 PM, couchdb - Andrés Orencio - lodopidolo > <[email protected]> wrote: > > Hello. I'm new in couchdb. > > > > I have some questions but I'm going to put them in separate threads. > > > > For this, I want ask you which is the better way to store documents and > its > > historical states. > > > > For example, I have products documents and categories documents. Products > > has one or more categories. This "relation" may change in the time, and > > product characteristics can change to. > > > > I want to store all document changes (categories too). > > > > Which is the better way to do this? > > > > Thanks you. > > >
