couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Weber <>
Subject Re: Would this be a sane use case for couchdb?
Date Thu, 10 Apr 2014 01:05:49 GMT
Well, this will likely start a flame war, but in my opinion, no.

This is based only on my opinion.  And it comes from my experience as a user which has been
exposed to having to write apps for both SQL and CouchDB (not an expert in either area). So
what follows are some disparate thoughts.

Couch is fast.  It stores documents.  Every document is in something akin to a folder, they
call a database.  Think like individual rows (docs) in a table (a database folder).

All the interface is done with HTTP calls (Get, Post, Put...)  That is a
 big learning curve.  And there is a lot of doc out there, all online. 
But it's spread out.  If you want to see how to create a view, one place
 has it.  If you want to figure out how to create a user, it's on a 
completely different web site.  Be prepared to spend a lot of time 
searching different site for answers.  So far, at least, I haven't found any info that is
different on two site when they do have the same topic.

The mail list is usually very helpful (unlike a different, un-named, C++ project where I pointed
out to the group a bug caused an access violation crash, and was told how dare me accuse them
of having a bug like that)

There is no referential integrity, because there is no foreign key.  And consequently, no

Couch refers to each table folder as a 'database', and each doc in it is a 'table'.  While
this is true from their point of view because that you can just add more data to a doc (add
rows).  But security is limited just to the folder (database).

The closest thing to a 'view' is a JavaScript function that enumerates each of the documents
in a folder.  But you can't chain views.  And it can't see anything outside it's folder

Imagine this:  A document for each employee. It has SSN, payroll, and bunches of other confidential
info.  If you stick all the docs in one folder, then you can run a view report (say, for
a IRS form 941). But you have to lock it down so only the HR guy can read them, otherwise,
every employee could create a simple URL to see every ones personal data. So now you can't
allow a user to update their own data because of the lock down.
Alternatively, you could put every employee in a separate folder (database) and restrict users
to their DB folder, but you can't write a server side JS view to pull everyone for the report.
Alternately you could break the data up (flatten and normalize it). They you run the risk
of losing referential integrity.

As for writing and debugging JS code, there is no debugger.  The system has evolved only
to the level of 'print' to a log.  And all the code is stored in strings that are embedded
in JSON documents, so the strings have the be stripped of CRLF, making the code unreadable. 
Kind of like 'minified' script code. There is no easy way to upload it, and if it crashes,
no easy way to debug, because the entire function is simply "Error on line #1".  So be prepared
to do a lot of trial and error...

All these issues can be worked around. (security, debugging, uploading and managing tools).
But it takes a lot of effort. So be prepared to write a ton of your own scripts to try to
make life easier.  Because no one really enjoys writing command lines that are 120+ characters.

There isn't any (or I haven't found any) thing like WebStorm, Visual Studio, or Fusion where
you can just launch an IDE and start creating.  So the lack of tools hampers development

To conclude my tome, don't believe that I an saying Couch has no value. Or to stay away from
it.  It's a really cool KISS based database system, especially for those of us who are tired
of DBAs who make monster schemas that take up walls to display.  However, like anything you
want to learn, start out with something miniscule and learn from there.

As I said, this is only my opinion from my experiences. I hope it doesn't get me excommunicated
from the list :-)

 From: Der Engel <>
Sent: Tuesday, April 8, 2014 1:45 PM
Subject: Would this be a sane use case for couchdb?

Hi, I'm a newbie trying to write his first real web application, couchdb
has interested me because of its http api and the thing that the data
model/structure of data of the app would probably be changing over time.
The webapp is going to be a invoicing software for certain niche,  so I
guess I probably need a DB were transactions are reliable and data
integrity is very good. I don't intend to run a cluster at first, but it
may become a necessity later on.

Would CouchDB be a good fit for this kind of application?

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