Getting Agile

Ted Neward has comprehensively described the issues revolving around Object/Relational Mapping (ORM) issues that are quite apparent in most enterprise application development these days. Although there may be some feelings surrounding Ted‘s comparison of ORM with Vietnam, I can not see how this analysis of ORM can be argued. For any development team which is evaluating an ORM, relational database, OODB, or other application data storage solution this article is a must read.

As I have probably given away in past blog entries, I tend to stay away from relational databases if I can. Unfortunately, I have found that I am not able to stay away most of the time due to customer constraints. My tendency is to use OODB and tuple space solutions for moving and storing data within my personal applications. In the OODB space I have used JDBM and db4o along with personal serialization solutions. In the tuple space arena I have predominantly used JavaSpaces implementations for my application messaging. I have tested TSpaces as a messaging platform but found it to be less effective for me than JavaSpaces.

Looking at the evolution of the enterprise towards Service-Oriented Architecture (SOA) I believe that data persistence can be reconsidered. There may be less of a need to develop our services with relational database storage. The reason for not using a relational database is to limit the specific knowledge of RDBMS platforms, consistency between application and stored data, ease caching, performance, and integration of data into the application development department.

On top of the article and further explanation by Ted Neward, TheServerSide reference to the article has interesting comments to chew on.