

Migrating to CouchDB - locopati
http://www.couch.io/migrating-to-couchdb

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

~~~
janl
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 :)

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

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

