Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Best way to model historical data
From: Robert Johnson <robert@rowanshire.net>
In-Reply-To: 
 <CABBNpWvLG=eeOX5BTMZ0sr_e5oM5ytYZan0ZeF7UVXV-8Bk2sQ@mail.gmail.com>
Date: Mon, 7 Nov 2011 11:05:44 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF502755-615B-451D-B03C-1F6BC808F8A8@rowanshire.net>
References: 
 <CABBNpWsxpOvEehY7qx+iqXSUmiQ=PmW_j4ysrypkLXuWHWT9qQ@mail.gmail.com>
 <CAHdjipLMO+aENY=eBoMeNrgT6uo3Yu5MaLJTzq03_Lz3ScMM0A@mail.gmail.com>
 <CABBNpWvLG=eeOX5BTMZ0sr_e5oM5ytYZan0ZeF7UVXV-8Bk2sQ@mail.gmail.com>
To: user@couchdb.apache.org

I wouldn't use multiple documents, but have a single document that has =
arrays of things that might change over time that you want to keep =
history for.

In your example you would have a block representing categories looking =
something like

{"categories": {
		"category_set": [
			"2011-10-05",
			"Components",
			"Resistors",
			"Surface Mount"
		]
		"category_set": [
			"2011-11-02",
			"Components",
			"Resistors",
			"Surface Mount",
			"Low Tolerance"
		]
	}
}

This way you keep a full dated history of changes and you only have to =
read a single document and last element in the array is the current one =
(clearly you would have to be ensure you update code to ensure always =
appended to the array)

Bob

On 7 Nov 2011, at 09:51, couchdb - Andr=E9s 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?
>=20
> 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?
>=20
> What do you think?
>=20
>=20
>=20
>=20
> 2011/11/2 Alexander Shorin <kxepal@gmail.com>
>=20
>> Hi,
>>=20
>> "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.
>>=20
>> 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).
>>=20
>> --
>> ,,,^..^,,,
>>=20
>>=20
>>=20
>> On Wed, Nov 2, 2011 at 2:20 PM, couchdb - Andr=E9s Orencio - =
lodopidolo
>> <dir.couchdb@orencio.org> wrote:
>>> Hello. I'm new in couchdb.
>>>=20
>>> I have some questions but I'm going to put them in separate threads.
>>>=20
>>> For this, I want ask you which is the better way to store documents =
and
>> its
>>> historical states.
>>>=20
>>> 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.
>>>=20
>>> I want to store all document changes (categories too).
>>>=20
>>> Which is the better way to do this?
>>>=20
>>> Thanks you.
>>>=20
>>=20