Jeff Davis:

So, my proposal is this: take a step back from ORMs, and consider working more closely with SQL and a good database driver. Try to work with the database, and find out what it has to offer; don’t use layers of indirection to avoid knowing about the database. See what you like and don’t like about the process after an honest assessment, and whether ORMs are a real improvement or a distracting complication.

I know a lot of applications using ORMs that worked perfectly fine. And I know applications that had to go around the ORMs or even got rid completely of them.

Here is a parallel to think about: ORM vs SQL is similar to always using a relational database versus using the storage solution that better fits the problem—as in using a NoSQL database or going polyglot persistence. An ORM comes with the advantage of keeping you inside a single paradigm (object oriented) at the cost of not being able to (easily) use the full power of the underlying storage.

Original title and link: Taking a Step Back From ORMs and a Parallel to the Database World (NoSQL database©myNoSQL)

via: http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/

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/