Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 15031 invoked from network); 3 Jul 2009 13:36:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Jul 2009 13:36:09 -0000 Received: (qmail 91286 invoked by uid 500); 3 Jul 2009 13:36:18 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 91237 invoked by uid 500); 3 Jul 2009 13:36:18 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 91227 invoked by uid 99); 3 Jul 2009 13:36:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jul 2009 13:36:18 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nrstott@gmail.com designates 209.85.221.191 as permitted sender) Received: from [209.85.221.191] (HELO mail-qy0-f191.google.com) (209.85.221.191) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Jul 2009 13:36:08 +0000 Received: by qyk29 with SMTP id 29so269744qyk.13 for ; Fri, 03 Jul 2009 06:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=V8jYI8nN4amYDf5VcYaC4NytGzofI2MNggtfvXL1X/k=; b=vn4adjTm1VKNyqAenMlGw3gTvWZvBFrD8z8zCNqNRfqB+BaRoOYjr0PeP81YxpgM1t RWmzymG5H4V7NEnWfPIUzbYoj8okyn6aKdTZcXfRPtb6mjdYJ/Ai4vHMXSoxAFMH1n4L cz9uNKzlvulj1PFcIAx9TntcbUUCHk2Tr1/rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Rjeoo1h2K/JPCQpWXY1rzpwHAMhZ6FePFntFO8K6ZXt+wbgrDc61hVS0CeBlfO9+2M B8ehMMH7KKHJsHNVhie82hVOC6gc9IuM0jYi8f78kpRYXiyJeyroNZ1Ru58uSP3PW7hX fjB2l/A0lOn+h2LYJxCrmyxKPFcMBM5wfF+CQ= MIME-Version: 1.0 Received: by 10.229.96.1 with SMTP id f1mr1012745qcn.103.1246628147559; Fri, 03 Jul 2009 06:35:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Jul 2009 08:35:47 -0500 Message-ID: Subject: Re: starting with couchdb, few general questions From: Nathan Stott To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016364270d2e70e51046dcd3bb3 X-Virus-Checked: Checked by ClamAV on apache.org --0016364270d2e70e51046dcd3bb3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable answers/opinions inline 2009/7/3 pawe=C5=82 kami=C5=84ski > hi, all > I posted this on erlang-questions but I have no response from them so may= be > 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 a= nd > reduce function to make them efficient. with select statement I just writ= e > 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-indexe= d 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 http://wiki.apache.org/couchdb/Introduction_to_CouchDB_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 RE= ST > 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 th= at > 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 feature= s > 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 wo= rk > on mobiles, browsers etc)? If I have one core machine then will the syste= m > 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=C5=82 Kami=C5=84ski > > kamiseq@gmail.com > pkaminski.prv@gmail.com > ______________________ > --0016364270d2e70e51046dcd3bb3--