ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Document Databases and Data Migrations

Sven Schmidt:

Since CouchDb is inherently unstructured, there’s no global schema that you manage to control your data’s structure. That’s often a good thing, because it gives you flexibility, but it can also cause problems, for example when you want to access documents without handling against all sorts of different “versions” of your document you might have.

When we first talked about document databases we said:

  1. no more ORM. Do a search or take a quick look at this list of NoSQL libraries and see if that still stands.
  2. no more schema constraints. The moment the structure of the data showed signs of evolving too rapidly, we started to look for ways to test document structure for inconsistency
  3. no more data migrations. Maybe no data migrations, but data versioning might be needed long term.

I think I’ve already written this once, but here it is again: the sum of constraints in a system is constant. The more relaxed the rules are on a component, the more constraints the rest of the components will need to support.

Original title and link: Document Databases and Data Migrations (NoSQL database©myNoSQL)

via: http://catbrainblog.wordpress.com/2011/12/19/couchdb-migrations/