Migrating to CouchDB | Hacker News Reader

Migrating to CouchDB

couch.io

48 pointslocopati4 comments

It's great to see folks providing commercial consulting/hosting/support for CouchDB in the same vein as Cloudera (Hadoop/HBase), MongoHQ (MongoDB), etc!

CouchDB is great but don't get me wrong ORMs like ActiveRecord and DataMapper have done a lot to to ease the pain and abstract away the nastiness of SQL. It’s not enough though. It’s like treating the symptoms and not the underlying condition. You still have to worry about joins, normalization, and other artifacts from relational databases. These issues leak their way up into your models where they don’t belong, and obscure more important logic. All of this isn’t an issue with CouchDB, and that’s the biggest selling point for me.

My favourite lame comparison to counter the ActiveRecord argument is that at some point AR in Rails was about 25k LoC while CouchDB was about 15kLoc. It's comparing apples to bike sheds, so it doesn't say much, but it's fun to look at the complexity of things that way :)

The problem is that most applications have instances where using a relation database is more natural and some where using a document store is more natural. Supporting two database products adds overhead. Postgres, DB2, and Oracle have (or will have) XML or JSON datatypes, allowing both methodologies to be combined in one database product.

For the author's specific problem, why not use triggers to populate a table with all of the calculations calculated out? Our in other databases like Oracle or DB2 you could use materialized views.

I haven't had much experience with database triggers, so it's hard for me to compare the pros/cons of using triggers vs using CouchDB.

Thinking about it, as far as the stats stuff goes, I don't think there is anything we did that can't be done via your suggested approach (triggers, materialized views, archive tables, etc). However, we're just a few developers here. We don't have a DBA. We're much more at home with Javascript than with the MySQL trigger syntax. So, CouchDB was a much more natural fit.

We're also making heavy use of the fact that CouchDB is schema-less. I'm not too familiar with the XML and/or JSON datatypes supported by the different relational databases, but some quick googling seems to indicate that querying the database for the contents of this data can be difficult. In other words, storing and retrieving XML appears to work OK, but (looking at Postgres) I can't seem to find a way to, for example, find all rows where the xml document in the 'xml' column has a <city> tag that is equal to 'Chicago'. Again, I could be very wrong here, I just don't see it after about 10 minutes of looking.

Working with documents is very natural in CouchDB, as that is what is was designed for. Not only can you easily find all documents with a city property equal to 'Chicago', but you can also programatically interact with that data in the map and reduce functions, using Javascript.

Reply on news.ycombinator.com