Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Nils Breunese <N.Breunese@vpro.nl>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Wed, 3 Nov 2010 17:36:53 +0100
Subject: Re: Using CouchDB to represent the tokenized text of a book
Thread-Topic: Using CouchDB to represent the tokenized text of a book
Thread-Index: Act7dVJ9pCRA/JzFR/+eua/Tc6EXMA==
Message-ID: <CBAFA60D-0F35-45C2-B9BC-87373D2BBB3A@vpro.nl>
References: <AANLkTins6kbFFz0HgFqxj9GH12UJF0myLPs0oUo4UxH-@mail.gmail.com>
 <AANLkTi=c-YTZiVi3FAi9vXaj61SxdH577FJ7h_xFprje@mail.gmail.com>
 <4E746F43-7973-4408-BB4D-2B3672BA9A73@vpro.nl>
 <AANLkTi=rGFJfM-9==Rhod7i+k4CZySP+vvneax0+De-Y@mail.gmail.com>
In-Reply-To: <AANLkTi=rGFJfM-9==Rhod7i+k4CZySP+vvneax0+De-Y@mail.gmail.com>
Accept-Language: nl-NL
Content-Language: en-US
acceptlanguage: nl-NL
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Weston Ruter wrote:

> Specifically, I'm looking at books that are in a constant flux, i.e. book=
s that are being edited. The application here is for Bible translations in =
particular, where each word token needs to be keyed into other metadata, li=
ke link to source word, insertion datetime, translator, etc. Now that I thi=
nk of it, in order to be referencable, each token would have to exist as a =
separate document anyway since parts of documents aren't indexed by ID, I w=
ouldn't think.

That's right. You'll definitely want to use a document per token here.

> I never thought about using a linked list before for this application, go=
od idea. It would certainly speed up the update process, but it would make =
retrieving all tokens for a structure between a start token and end very sl=
ow as there would need to be a separate query for each of the tokens in the=
 structure to look up each next token to retrieve.

Yep, that's the trade-off of linked lists. O(1) for inserts, but O(n) for l=
ookups. Arrays are the other way around.

> As I mentioned above, metadata and related data are both going to be exte=
rnally attached to each token at various sources, so each token needs to  r=
eferenced by ID. This fact alone invalidates a single-document approach bec=
ause parts of a document can't be linked to, correct?

Correct. Well, you could maybe contruct a document with sections which have=
 ID's of their own, but that doesn't sound very relaxing.

Nils Breunese.
------------------------------------------------------------------------
 VPRO
 phone:  +31(0)356712911
 e-mail: info@vpro.nl
 web:    www.vpro.nl
------------------------------------------------------------------------