On Mon, Nov 7, 2011 at 1:51 PM, couchdb - Andrés Orencio - lodopidolo <[email protected]> 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(: -- ,,,^..^,,,
