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: <6FC329DB-6EC2-49BE-9DFF-A030767CEC45@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <521183240810121228u3eef309dw7e44141701401e4e@mail.gmail.com>
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: When to use CouchDB, when not to...
Date: Tue, 14 Oct 2008 17:35:10 +0200
References: <521183240810111938s2d60320fo30e47cdf22acc7d4@mail.gmail.com>
 <521183240810121228u3eef309dw7e44141701401e4e@mail.gmail.com>


On Oct 12, 2008, at 21:28 , Lance Pollard wrote:
> Just some thoughts on how and when to use Couch vs. MySQL. Any  
> answers to
> this question would really help out a ton.

My take on this is that the structure of the data is less important  
but the
types of queries you want to run are. CouchDB can handled structured,
unstructured, often- & lesser-frequent updated data just fine. An RDBMS
will only go so far providing performance on unstructured data. There's
a small sweet spot for CouchDB.

The bigger thing though is that an RDBMS handles dynamic queries
quite well and CouchDB doesn't. A dynamic query is a query that a
developer can't predict when developing / deploying a system. CouchDB
views let you mimic dynamic queries a great deal, but you need to be
able to anticipate what sorts of queries are run and on which properties
they should be run against. If you run into a situation where you need
to create a new view on-the-fly for immediate consumption or even think
about using temporary views, you need to make sure your data set is
rather small; more likely though is that CouchDB is not the right  
choice.
(Yes, if you query an RDBMS on an unindexed column, you are in trouble
as well. Still.)

Luckily, views are flexible enough that I'd like to apply the 80/20  
rule and
say they solve most of our user's problems, but I haven't made a  
scientific
analysis yet, so you have to take my word for it :)

Additionally, the plugin API that Damien, Paul and Chris are working on
lets you hook up other index/search solutions that can complement
CouchDB where views are not enough. This will nicely solve the sync-
issue that can (will) arise in a hybrid setup. (Not saying a MySQL +
CouchDB approach is bad, its just hard :)

Cheers
Jan
--