Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <84AED9E0-21CE-404F-A852-DAA5C237D149@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <gbgce2$qo9$1@ger.gmane.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: 3 Newbie questions
Date: Fri, 26 Sep 2008 12:31:53 +0200
References: <gbg36q$n8g$1@ger.gmane.org>
 <122EE525-9024-4254-ABAA-985D5B507960@apache.org>
 <gbgce2$qo9$1@ger.gmane.org>


On Sep 25, 2008, at 17:54 , Will Schenk wrote:

> On 2008-09-25 10:21:05 -0400, Jan Lehnardt <jan@apache.org> said:
>
>> a) "The value returned from a reduce should grow at a rate no  
>> bigger  than log(N) of values processed". This is why you see your  
>> view being  slow.
>
> Where is this quote front?

IRC, sorry :)

>> See above, wrong conclusion. Treating databases as tables is a   
>> terrible idea. Sorry RelaxDB folks. See http://upstream-berlin.com/2008/09/25/a-couchdb-primer-for-an-activerecord-mindset/ 
>>    for a discussion on different Ruby libs.
>
> I'm not sure that RelaxDB does this exactly, but... why is it a bad  
> idea?  In my case, I suspect that moving "blobs" to the attachments  
> will basically solve my problem, but it seems like you could use  
> different databases in the same way that you'd shard tables in a  
> more traditional setting.

Looks like this is what ActiveCouch does, thanks Paul. It is not per- 
se bad to use multiple databases to separate data. Only the "on type  
of documents per table"-thing might reveal a slight misunderstanding  
about the differences of CouchDB to an RDBMs. Call it a "design  
smell" (think goto), not bad, but should be used with care.

>> Again, no big data-roundtrip problems. See above. With views, you   
>> could do each dimension in a separate query and then intersect the  
>> two  results in your application. Or employ a GIS indexer /  
>> searcher over  the external indexing interface.
>
> But that's not where I want to put my datafiltering logic!  And in  
> this case, you'd get a lot of extranious crap -- I don't need to get  
> points of interest from rome if I'm looking for stuff in nyc (same  
> latitude, different world).

Notice the "could" :) I'm just pointing out the (probably easiest)  
solution to get that. Yes it does have the drawbacks you describe and  
might not be suitable for you. I'd suggest you try and build it though  
and see if it turns out to be a real issue. If it is, an external GIS  
indexer/searcher-combo is what you'd need.


> Where would I find information about the external indexing stuff?

See: http://svn.apache.org/viewvc/incubator/couchdb/branches/lucene-search/
and: http://github.com/davisp/couchdb/tree/external as well as the  
couchdb-dev
and couchdb-user mailing list archives and the documentation wiki

Cheers
Jan
--