incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From couchdb - Andrés Orencio - lodopidolo <dir.couc...@orencio.org>
Subject Re: Best way to model historical data
Date Mon, 07 Nov 2011 09:51:12 GMT
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 <kxepal@gmail.com>

> 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
> <dir.couchdb@orencio.org> 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.
> >
>

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