couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sjtirtha <sjtir...@gmail.com>
Subject CouchDB vs. SQL
Date Thu, 20 Aug 2009 20:05:25 GMT
Hi people,

I'm new in CouchDB. Before I looked into CouchDB, I was kind of
investigating what other no-SQL DB exists in the world.
There are MongoDB, Hadoop, Hypertable, Cassandra (correct me if I misspelled
any names).
And I found out the two big no-SQL DBs are Hadoop and CouchDB. Hadoop is
very interesting, but it is very big and complicated.
On the other hand, from some presentation I have the impression, Hadoop
should not use for a normal web application.
It is more for analytics data like Google and Yahoo do.

So I came to  CouchDB, which is also very interesting from the design and
implementing language(Erlang) point of view.
But somehow, it still does not 100% convince me to replace SQL with CouchDB.

One of the reason I like CouchDB very much is the  schemaless thing.

But I'm still not sure regarding following points:
1. performance. It is faster or same fast as SQL?
2. how can I reduce the data tranfer between my application and CouchDB,
when CouchDB always sends the whole document, although I only need a part of
it.
    This can be done very easy in SQL by selecting which columns should be
retreived from DB.
3. CouchDB support MVCC which is very good. But how is it, if I really want
to lock a document and other people should not be able to write.
4. Can I build a View based from other View?
5. Is there any Document Model Normalization as we all know in relational
DB? Because the Model Normalization from relational DB is a basic theory how
the relational model should look like. In CouchDB, it looks like that I can
do everything I want, but it may be a drawback for me in the future, if I'm
not design the document model very well.

CouchDB always put HTTP and Restfull as a very important things. But I don't
thing it is really complicated for SQL DB vendor to build a HTTP/RESTful
communication layer to their DB.

regards,
Steve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message