couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: complicated entities with i18n
Date Thu, 09 Apr 2009 18:41:14 GMT
Hi László,

On 3 Apr 2009, at 15:44, László Bácsi wrote:

> this is my first mail to the list so I'm László Bácsi from Hungary  
> working
> for Virgo Systems as the chief Ruby engineer.
> We're in the planning stages for a client project. This involves a  
> number of
> models some with overlapping properties and a lot of associations  
> between
> models. For example, there's an Institute model which there are 9  
> different
> types of, each with their own specific properties and 6-8 properties  
> which
> are available for every type of Institute. Additionally each model  
> has some
> properties which needs i18n.
> Designing this with RDBMS is a nightmare. I was thinking about using
> CouchDB, but I have a lot of fears regarding this:
> Lack of experience: there will be at least 3 people working on the  
> backend
> side of the project excluding me and the others have no experience  
> with
> CouchDB, schema-less databases and MapReduce.

I found that the CouchDB way of things takes a little getting used to,  
but only
if you have a background in relational databases. If you can leave  
that behind
(or haven't been "spoiled" yet :), CouchDB is quite approachable.  
There are
a number of examples on how to do queries in M/R in the wiki* and some  
in the presentations, that you can also find on the wiki**. Geoffrey  
excellent screencast on CouchDB & Rails*** is also a good introduction  
thinking in documents (of the 90 minutes, only 20 are Rails specific,  
so it is worth
watching / showing the screencast). Lastly, *plug*, there is "the  
book"****, the
available chapters already include some significant material and while  
we are
adding more, you and your colleagues will have advanced with CouchDB  
too :)


> Early stages: I've been using CouchDB in a personal project since  
> December.
> During this time I had one occasion where I had to upgrade to get a  
> new
> feature and that upgrade needed a newer Erlang version which I had to
> compile from source because there were no packages, etc. Even after  
> the
> successful installation I had to rewrite some of my code to  
> accommodate
> changes in CouchDB's handling of design documents.

CouchDB is still a moving target, but changes are usually minimal and
well documented*. Migrating very large database to newer file formats
can be a little tricky, but it is not impossible.


> ok, this is becoming long, so I wrap up. Would you build a project  
> like this
> which would need 4-5 month of work with a 4-5 people team with no  
> experience
> on CouchDB? If yes how would you approach the problems I mentioned?

If you feel confident that you can learn CouchDB along the way (I'd  
say yes),
and the the support resources available (this list is terrific, in my  
are sufficient for your needs, CouchDB is not the worst choice. If you  
get your
developers up to speed in a reasonable amount of time, you might want to
publish a proposed architecture of your system here and the community  
give you a review and possible hints and tips for improvements.

Maybe members of the list that are already basing a project on CouchDB
can share their experience?


View raw message