我(某老外)为什么选择CouchDB？

I’ve always hated SQL, so I’ve always found the nosql movement pretty interesting. There was a point in my programming “career” where I was very much into python and javascript. and json and all the dynamic programming languages stuff.

I really hated structure and felt it imposed on my creativity. I’ve recently been having a strong shift of attitude about this whole thing and I’m starting to see merit to the structure of static typing, specially since I’ve been playing around with Go recently.

But, I still hate SQL.

For a while I’ve known about 2 json-based nosql databases: MongoDB and CouchDB.

I tried to learn and use MongoDB for a while. It was during the same period of my life when I was trying to learn NodeJS (big mistake and big waste of time). Anyway, Mongo’s api is not bad, but their query language didn’t sit well with me. It felt not much different from SQL in it’s obtusity and obscurity and verbosity. Ultimately I failed to do anything productive with mongodb because I was trying to use it in the context of Node and my whole experience with NodeJS was bad.

I failed to be productive with NodeJS for reasons related to the way it’s designed, and so my failure to use MongoDB was not really a failure of MongoDB, but a failure of NodeJS. Still though, it did leave a bad impression about MongoDB for me.

I didn’t really get into CouchDB until after I realized what a terrible mistake Node was. At that point I was trying to go back to Python/Flask because I justknew developing on that platform. would be so much more pleasant.

I got interested in CouchDB when a roommate mentioned good things about it as it came up during a conversation. So I decided to give it a go. I learned by reading the official guide book: http://guide.couchdb.org/

Couch has several features that appealed to me.

First, it’s a pure json document store. This means that all documents are json, and they can have any number of fields, and you can add new fields to an existing document at any time. There’s no schema and thus no migrations to manage.

Second, its “view” system. Views in couch are a way to create secondary indexes, and essentially the only way to make queries (other than loading a document by its _id). Views are basically “cached” results of “map” functions.

For example, say you have a many-to-one relationship between an owner and a list of items, where each item keeps the owner id in a field. How do you get a list of items by owner? You create a view matching owner_id with item_id and query that view with the owner id. (I’m not going to go into any further technical details — you can read about views in the guide book (link above)). 

What this means is that for any query, you have to create a view first. You can’t just make an arbitrary query like SQL databases or MongoDB. This might be a good thing or a bad thing, depending on your mood. I personally think it’s a good thing, because it makes it easier to reason about indexing.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/301743/viewspace-742429/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/301743/viewspace-742429/