couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Stott <>
Subject Re: starting with couchdb, few general questions
Date Fri, 03 Jul 2009 13:35:47 GMT
answers/opinions inline

2009/7/3 paweł kamiński <>

> hi, all
> I posted this on erlang-questions but I have no response from them so maybe
> you can help clarify all this.
> recently I ve started to look at couchDB and what I see sounds great but I
> have few general questions
> 1)when it is better to use document oriented db over RDMS or in your
> opinion
> it is always better to use couchDB:)

When your data is schemaless it's better to use a schemaless DB.  If your
data would normally be stored in a document, then couchdb also seems like a
good choice.

> 2)why schema free is good, how then ensure that what somebody puts to db is
> what it should be especially when JSON can handle any data type and it is
> easy to make a mistake

Validation is a part of couchdb.  You can write a validation function in
javascript to ensure data integrity.

> 3)as a old SQL developer Im force now to think how to implement all map and
> reduce function to make them efficient. with select statement I just write
> what I want and leave all to the system, dont I?.

I'm sure as an old-sql developer you realize that if you write just any old
query, it's not going to perform well.  For example, querying by non-indexed
columns is going to be a nightmare for performance.

CouchDB views are indexed.  Check out the wiki for more info about how
couchdb views work.  Here's an intro to the views

> 4)how to design my db, curently my db is about 500 normilized tables,
> master
> to items tables, so I understand how to aggragate with MR but how to join
> and how to make it work fast and use as small disk as possible and that
> data
> are not redundant. I understand that each document type is in separate REST
> path and connect children to the document I should just put them to
> path/docs/coffe/items. what about normalization and redundancy.

Normalization is not something that document DBs concern themselves with.
 Often something you have multiple tables for will be one table in a
well-designed document DB.  Redundancy is often useful/necessary as well.  I
know this sounds terrible to a long-term RDBMS user.  You've got to
remember, this is a different world :).

> 5)If my RDBS is running on 2core (ore sometimes one core) machine, and that
> machine is alone server storing data from local clients is there any gain
> of
> using systems such as couchDB or others (ok replication and other features
> are still nice)

You'd have to benchmark your particular app to see if couchdb with a
well-thought-out schema out-performed your RDBMS.   For some tasks I'm sure
it would.  For others, perhaps not.  If you're inserting a ton of documents,
couchdb with its bulk insert would almost certainly outperform the RDBMS
from what I understand, though I do not have benchmarks to show this.

> 6)this is somehow related to point 5) what scale down really means (to work
> on mobiles, browsers etc)? If I have one core machine then will the system
> be fast enough than RDMS (sqlite)

Couch seems pretty light-weight.  It runs great on my 5 year-old Ubuntu
laptop.  It is a dual core, but it only has 1 gig of RAM.

> thanks for helping me in that
> pozdrawiam
> Paweł Kamiński
> ______________________

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