Well, you can guess the title right there (Keep it Simple Stupid). Another title could have been (for controversey). Why the heck are we still dealing with RDBMS platforms and architectures ?
So living in the Object world of Java I have come in contact with many databases. Sybase, MSSQL, PostgreSQL, MySQL and some Oracle (in that order of exposure).
In each case I have had to deal with the RDBMS and the Relational Mapping layer (RM).
Experience has whispered to me that .. "there has to be a better way", but certainly until about a year ago, shy on stating that there has to be a better way. I have known about ODBMS's for as long as I have known RDBMS's but have never worked with one.
Certainly, legacy (and I mean that in the "ODBMS to RDBMS sense") platforms have to stay RDBMS and that is where OR mapping stays, but .. I want a simpler system.
I blogged some time back that my goal for the next project is to make it sans-SQL. Now why on earth would I want to do that ? Well for one, I want to reduce complexity. It's that simple really (Keep It Simple Stupid).
This is such a "hot" topic (many people have an opinion) that I am going out on a little (hopefully stong) limb and stating that RDBMS platforms are just simply getting long in the tooth and now is certainly a best time to move away from the RDBMS.
Why (why are you being so nuts, why move away from proven technology, why ?)
I have just finished listening to a very good talk by Ted Neward on TheServerSide
The Webcast Talk - Object/Relational Mapping and the Vietnam of Computer Science - Expert Webcast
This talk centres around the idea that when working in the Object space, we should just not use RDBMS's. For background reading, the comment of OR Mapping being the "Vietnam of Computer Science" is found here at his blog.
One of the good quotes, which aligns with my previous post is this.
Ted was talking about the "lure" of OR Mapping
"[OR Mapping has a]... selling point that says, I don't have to think about SQL, I don't have to think about tables, I don't have to think about manually unwrapping this stuff myself.. phew .. I don't have to worry about these issues anymore, and then to get bit by them .. at the 11th hour"
So true, with Hibernate, OJB, and JPA (etc etc), SQL is still there when you have to do complex stuff. It is still there when Crystal Reports or JReports or platform X comes into it.
I remember many a time sitting at night trying to tune that sproc that was mapped to my business service pouring over SQL, just to get my data right and quick. That HAS to Cost something.
There has to be an extraordinary TCO attached to using OO and an RDBMS, one which could be lost if we remove the RDBMS altogether.
Of course, there are problems, how to we make sure the ODBMS is quick, and efficient, and what do we do when we want reports ? (These answers I am going to find out)
Ted mentioned, rightly, that it all depends what is on top of the paltform, is it Objects, or relational Data. What is the priority of the platform ?
Back to the TCO. So If I have no DBA (only Operations looking after the "service" and "data" tier) and I have no need for SQL developers (if there are sprocs involved) and I don't have to worry about OR layers .. It has to mean that I have less to worry about, surely, which means that "time" to market, TCO etc is lower. It just has to .. It has to mean a simpler system.
This KISS principle, A very interesting WebCast that.
So where to from here ? I have decided that my projects will not use *SQL. So that means I have to choose an ODBMS platform.
Two issues that were rasied in the Webcast which are VERY real are the following.
- How do you administer the chosen ODBMS ?
- How do you monitor the chosen ODBMS ?
Very true, kind of a worry (possibly). We'll see.
No comments:
Post a Comment