Friday, May 16, 2008

Derby database in applications and why I don't like it

I have tried using some applications that uses Derby as the backend (I wouldn't want to pinpoint the products) and when the product is started, it takes a very very very long time for the derby to initialize (because one particular produce have a tool tip when you mouse over to tell you the status) . It took nearly more than 2 minutes to initialize. On the other hand, I have made a couple of applications using H2 database as backend. I didn't use the latest H2 and it's those around version 1.0.65 for H2. The speed difference was so different. It quickly started and the apps took only less than 2 minutes or even 1 minute and below.

Just a side note, H2's jar file contains: SSL Server , TCP Server , Postgres Server (to allow Postgres protocol) , command prompt shell , Web base console , database engine , JDBC and allow both client-server and embedded mode.

I doubt if Derby's jar file even have an interactive console like H2's or have the array of tools packed in like H2's.

When I first used Derby, i have no idea how to start it or even run it. It's so unfriendly and you need to hit in chunks of commands into your OS's command console/prompt. For H2, all I need is click on the H2 jar file and it would add a small task bar icon in my OS and pop up a web page with a friendly console GUI.The web console comes with some GUI goodies like auto fill in forms ...etc... It's so much more presentable and easier to use than Derby. When I use H2, the first thing I felt was me being impressed by how well it pressed and how simple... all in the click of a jar file and web based GUI consoles come to your aid. If I need another session , I just go to the task bar, click on the H2 icon and another session is there. If I want to terminate the database , I just exit the icon

Overall, the minute I use H2 , I am not so badly lost as Derby. For the Derby team... if you want to be any better than H2, first start from redoing your appearance and usability.

Another thing, imagine your applications with backend have some SQL problem and you need to debug it in the deployment machine but you don't have any other tools except the jar files. For H2, you just need to click the jar files, key in the connection path , username and password and you can start to debugging , restoring any corrupted databases , backup (hot and cold) ...etc... no complications. Derby ... up till now, I tried to get into the Derby database of the applications containing Derby which I refuse to pinpoint earlier... and I still haven't got an idea to access it's database. Maybe I am a noob in using Derby. From this scenario, if you are a developer or maintainence officer, I think you are more likely to choose to maintain H2.

So from here, H2 wins hands down not only on the usability and ease of using and more hassle free than Derby, H2 won because it has lots of tools equiped inside it's smaller than 2 MB jar file. Can Derby do it ? Yes ... but are they moving towards it and effectively be seen as equals to H2 to my view ? No .

Derby developers, you have lots of usability issues.

H2 developer(s) and to it's chief , Thomas Mueller, well done ... continue on the good work ! :D

After the good first time experiences from H2 , I have rather become a fan of H2 because of the good impressions.

No comments: