couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@couchbase.com>
Subject Re: Would this be a sane use case for couchdb?
Date Thu, 10 Apr 2014 04:15:29 GMT

On Apr 9, 2014, at 6:05 PM, Scott Weber <scotty2541@sbcglobal.net> wrote:

> 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). 

I’ve never seen anything that compares a CouchDB document to a table. They aren’t like
that at all. 
Documents are comparable to rows in a relational database.
CouchDB doesn’t have any equivalent of a table because it doesn’t require rows/documents
to have the same structure, and it doesn’t have different ID namespaces comparable to table
primary keys.

> But security is limited just to the folder (database).

Read access is limited, yes. But you can have fine-grained write access on a per-user basis
or by validating data in documents.

> 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 (database).

CouchDB views aren’t really like SQL views, and there is a lot more to them than JavaScript
functions. They’re indexes. As indexes they’re more powerful than SQL indexes, but the
query capability is more primitive.

> 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.

That’s assuming you even wanted to give users direct access to the database. It’s not
necessary; you can have an app server that manages the database and has a web interface (or
REST API or whatever) for users. Which is what you’d do with a traditional database like
MySQL anyway.

I work on a DB server that’s compatible with CouchDB (but not based on it) that does support
exactly this kind of fine-grained access control. Contact me off-list if you’re interested
(I’ve gotten flak recently for mentioning it here because it’s not strictly speaking CouchDB.)

> 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

This is what “CouchApp” development frameworks like Kanso are for — they let you store
your resources and view functions in local files and then compile/minify them and upload them
to the database for you.

> 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
severely.

*Shrug* I’ve never used an IDE like that for web development. There will never be special
IDE support for cutting-edge systems because the tools always lag behind; for example, I don’t
know if there are IDEs for Rails nowadays, but it used to be everyone used regular editors
like TextMate or Emacs. IMHO saying this hampers development is an excuse (kind of like saying
you can’t write good songs because you have the wrong brand of guitar.) The early Rails
developers created websites like Basecamp that went beyond what anyone had done before, with
no special tool support.

Re-reading that, it sounds too much like the grumpy grandpa complaining about how lazy today’s
kids are. I recognize that IDEs are great and can make things easier or faster. But they’re
not necessary, and there are other advantages to working with a newer system before everyone
else catches up to it.

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