Saturday, June 27, 2009

Rethinking relational database backed domain mindsets

Yes there are issues with relational databases, but they have been have been a developers' bread and butter.

Most of every issue has been solved in some form or another.
The data duplication and inconsistency is usually solved by normalization.
The impedance mismatch has been solved with ORM layer.
The latest problem though of trying to distribute the database is becoming an issue though. The distribution part is emerging as companies are trying to scale out and utilize more hardware or VMs to solve the mounting pressures of growing number of hits.

So what is the solution to this problem? Well, it appears that relational databases are being overtaken by the key/value, or map-reduce type of databases, like: Amazon's Dynamo, Google's BigTable; and the open-source types like: BerkeleyDB, CouchDB, HBase, Hypertable, Tokyo Cabinet, Project Voldemort, Redis, MongoDB and the list goes on.

Object Databases (db4o) and hierarchial databases like Neo4j are in a different category.

These provide a way to not only distribute your databases, but also provide speed and efficiency that is needed. You also get eventual consistency.

There is a draw-back to this though. The drawback is that we need to rewire the way we think about domain design. There are no more relations per se and the eventual consistency means there is a chance for inconsistency?

So, how do you go about switching your relational database type of mindset to this one? Do you need to rethink the way you design the structure of your domains?
Maybe this just needs some type of a eureka effect to take place to get this.
Does anybody else have these types of questions?

No comments: