prose :: and :: conz

Who produces and consumes your DB?

I’ve been frustrated to no end with accessing a SQL DB through Hibernate on the job. Fortunately, I’m not the only one either here at work or around the globe. There are more than enough blogs written about the impedance mismatch (and I LOVE that term) between SQL and OOP. Despite the frustration of developers and the proliferation of good literature explaining why we are right to be frustrated, I find folks are still scared to step away from the old familiar SQL.

I believe one of the reasons for the hesitance to utilize NoSQL DBs is the worry of tying to a particular technology or programming language. For instance, you may be fearful of Neo4J because you can only use the DB from the JVM ecosystem (Yes, I know there is also a REST interface available). There is this thought that perhaps another application will need to access the DB. But let me ask you this question… Who produces and consumes your DB?

Chances are, it’s your application and your application alone. Chances are, you have no plans to throw away all of that work and build a new application that will use that data. In fact, DB schemas are often so complex you would never want to write something else to access that data. Instead, you would expose the data indirectly as a web service.

Why are we still going through all of this trouble to mash our objects into tables, when all we’re going to do is bring them back to life as objects? Just use a DB that makes sense and makes the job easy to get done.

Olde Comments
  1. […] with the dynamically-typed MongoDB for my project. Given that my application is the only producer and consumer of my database, and I’m using static typing, I don’t see much value in having a static schema […]