Monday, 14 May 2007

Desire vs Need .. ODBMS vs RDBMS

I have been on the think track of not using SQL for sometime now and have completely come to th conclusion that it is entirely possible. Possible in the sense that a decent well founded ODBMS will suit my need.

I mentioned a few things that needed to be investigated in order for the switch to be solid.

1. Administration - So presumably, the chosen ODBMS (Server, Platform) will provide a level of administration, such as object browsing, log, db maintenence etc What evere the underlying "architecture" is, there has to be tools to see it, so it is not a black hole. One of the nicesties of an RDBMS is it is not a black hole in as much as SQL from any compliant tool gets you to your data, a plus.

2. Monitoring - How can we monitor this beast. I put this here because in my line of work, there are clear distinctions between those who build and those whome maintain and the maintainers want a system, that, well, can be maintained. So it's important.

SO, where is this desire and need. The desire, I want to switch, the need. The project I am embarking on does not have the funds to splash around and this puts it squarley into the hands of OSS for the chosen ODBMS. If you look around, it leaves only a few choices. After you weed the crappy and incompatible ones out, the clear winner is db4objects. But ahh, Here is my catch, db4o is GPL based, and you HAVE to code with it, ie, embed it. Which means that I can't use it, unless you buy their commercial license.

What is lacking is a non-viral license ODBMS to the quality of db4objects (Apache 2, Mozilla, LGPL) such that it suits the needs of this "commercial" yet cost constrained project.

So, there is my desire (ODBMS) and need (RDBMS). I must (need) have a running architecture with which to start.

I must make sure that this "platform" chosen (Hybernate, MySQL (PostgreSQL)) is "removeable" for the day (if) when a compatible ODBMS comes available, or the project at hand makes some money to warrant a change.

Hrmm, certainly has you thinking. I will look further into the db4o world. Here is a thought: if db4o were running as a server, in the SAME way that MySQL runs as a server, then there is no impact to your licenses. db4o is well within it's platform, wrapped in server code, .. hrmm .. cheeky. Let me take look at that.

So, the server code could be GPL'd next to db4o.

2 comments:

Christof said...

Ramon,
thanks for the positive feedback on db4o.
I think the GPL/dual license of db4o is not a catch per se, because this commercial model enables us to invest into the product and make it as good as it is.
You have two choices:
- either you are open source/GPL yourself, then you can use db4o under the GPL for free
- you are not subscribing to open source, then you need to get a commercial license for db4o, which, BTW, is very affordable (somewhere between $1 and $1,490)
We have decided to make db4o very easy, so you don't need to buy support. But we do ask for a license fee contribution, if you make money off your products based on db4o.
More about prices and licensing on db4objects' website:
http://www.db4o.com/commercial/purchase/
Cheers,
Christof

Ramon said...

Thanks Christof,
Yes it truely does look good. Native queries just completely struck me as "wow" that makes sense.

Fantastic work truely. I so hope that the ODBMS camps(s) can forge a way, so tried in the past, which makes ODBMS seem more than an option for the DB that RDBMS.

The TCO involved is actually tremendous, and it shouldn't be!

Current 5 booksmarks @ del.icio.us/pefdus