Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jurgvanvliet@gmail.com
 designates 209.85.219.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:content-type:content-transfer-encoding
         :mime-version:subject:date:x-mailer;
        b=CpbC7qgjQwy8s7rKheYsJ+bXDqTWjHUjjxn4QGbNnLTygOqjw3W5kPZRzBtR6GC9AU
         AXAWQIiNpV6LdgGCEyY/W8PHnVJFwBxpIqXsHPFQIJ2MHuookNm4fBv/LvqdFgBjBUnM
         nv/JwqnPkT8UcTVbUdc/j7za4GbObZEvY6Fwg=
Message-Id: <1DEB5002-D380-48D1-8C6A-3237420323B2@gmail.com>
From: Jurg van Vliet <jurgvanvliet@gmail.com>
To: dev@couchdb.apache.org,
 user@couchdb.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: struggling with couchdb in production
Date: Mon, 25 May 2009 21:18:01 +0200

guys and girls,

i am a 'real' user of couchdb, and i am having a lot of fun with it in  
addition to creating real value! but it is far from easy, especially  
in combination with a framework that is built around relational  
databases like rails. and still, after 4 months of intensively working  
with couchdb i am still a big fan.

but couchdb is not finished yet. and i don't mean not finished in the  
sense of the software program that you can run, or the community that  
is building this. what i mean is that there is no documented approach  
to model real world problems in a couchdb way. you can search but the  
most interesting examples are to clarify the idea, or to show that it  
is possible. but nothing that helps me think about when to use a  
document, when a database, when a view, etc. etc.

we have taken a couple of wrong design decisions the last couple of  
months. you can call it ignorance, or hindsight, or something else. i  
think it is just the lack of a good framework for thinking couchdb.

when you make your relational database model, your tables, your rows,  
your indexes, etc. there is a large body of documentation that helps  
you approach the problem. and even with years of practice, and people  
having the word database and administrator in their jobtitle,  
designing your database models is just difficult. (there are really  
not many people i want to have thinking about tables and rows and  
indexes.)

so now we have to make this paradigm shift. how are WE managing to  
struggle through this?

one of my personal insights is that couchdb is so different from a  
relational database that it is best approached as if it is the  
opposite. in a rdb you 'minimize' the entity of information, you  
normalize until it is small enough to still have meaning. once  
everything is deconstructed you add rules (validations) your data must  
adhere to. having done that you start to put it back together using  
joins.

in couchdb this pattern doesn't work very well, at least not for us.  
we learned it is easier to put as much data together in one document  
as possible. my rule of thumb of when to stop is in distribution. i  
often ask myself 'do i want to keep this together when i move it to  
another database?' once you have your documents views are very  
convenient to take your documents apart.

a database in couchdb is the place where work comes together, in our  
case this is the location where a group of people shares. combining  
information from different databases will be necessary. and i really  
have no clue yet how to approach this problem. so anyone?

today i found myself in a sort of discussion with jchris and jan (i am  
sorry for the other jchris' and jans, but everyone knows who i mean.)  
guys, what i mean to say is that i am happy with your work. but your  
work is very very important to me. i think my work along with all the  
work of your users is what is going to make this movement great. if  
you help us succeed, you will have what you want.

(the reason i sent it to both lists is that i think this 'couchdb way'  
of working is something that is not the problem of use OR development.  
it is necessary to make everyone work together and find out where  
couchdb's future lies.)

groet,
jurg.