couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Best way to model historical data
Date Mon, 07 Nov 2011 13:37:22 GMT
On Mon, Nov 7, 2011 at 1:51 PM, couchdb - Andrés Orencio - lodopidolo
<> wrote:
> 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?

No, I've told about immutable document per historical event. Let me
try to show this idea on next example:

You have some document that describes customer with fields: firstname,
lastname. This customer makes order request, so you have to create
request document for that event. By could you store only customer
document _id in request document? No, you're never shouldn't. If
customer had changed his lastname: she could just get married and
takes husband lastname. So this would be same person, but with
different set of first/last names. If you update customer document
data, so all your reposts for all her orders in past will have
lastname from future! Probably, you would like to keep customer
document reference within order document AND keep all vital refereed
fields within same document from related to prevent them from changing
in time. In same time, her birth date doesn't cares your order
document because it haven't figured in future process.

In ideal case, you'll have to store full copy of related document, but
you may not always do this.
Same thing is true for all other data kinds that should be historical,
but also have to keep references to other documents in same time.

Sorry for my English, but I hope you'll have understood my idea(:


View raw message