It's too late to post on your blog, unfortuanately (great article btw) but I think your article hits the nail on the head. A couple points I would make though

It's too late to post on your blog, unfortuanately (great article btw) but I think your article hits the nail on the head. A couple points I would make though is that I don't see anything wrong really with using an ORM plus views to encapsulate data. INSERT INTO invoice isn't all that bad if invoice is a view. Data operations are still encapsulated. The second point is that I am a relative fan of loosely coupled systems. Loose coupling gets away from CAP theorem problems because each system is autonomous and can always defer interop with other applications until later. On the other hand your centralized RDBMS goes down and every app that needs it dies with it. How many apps we want entangled in that way is a business decision but there are tradeoffs on both sides. That doesn't mean endorsing the NoSQL approach though. I maintain that you can't have "eventual consistency" in any meaningful, guaranteed way unless you always have "absolute local consistency" within some scope. Postgres-XC defines that scope as cluster-wide. In a loosely coupled system it could be each individual node. For this reason BASE doesn't work for anything that is important. It reduces to: Best-guess Attempt at Semi-consistent Eventualities. Lesson is: not only do you want to encapsulate your data, but anywhere that you want eventual consistency, you need to have local ACID compliance for some defined scope of local. This is a big issue that NoSQL db's have and that they cannot solve (due to CAP theorem issues). If only it were absent from the RDBMS world. I groan every time someone asks for "multi-master asynchronous replication."