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
more
in the presentations, that you can also find on the wiki**. Geoffrey
Grosenbach's
excellent screencast on CouchDB & Rails*** is also a good introduction
into
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 :)
* http://wiki.apache.org/couchdb/View_Snippets
** http://wiki.apache.org/couchdb/Presentations
*** https://peepcode.com/products/couchdb-with-rails
**** http://books.couchdb.org/relax
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.
* http://wiki.apache.org/couchdb/Breaking_changes
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
opinion)
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
can
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?
Cheers
Jan
--
