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:
- no more ORM. Do a search or take a quick look at this list of NoSQL libraries and see if that still stands.
- 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
- 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 ( ©myNoSQL)