Hi. My name is Barry, and I'm a DBMS addict. You have to be if you're in the IT field. As an i5 junkie, my DBMS of choice is DB2. I love its stability, its power, and its lack of a requirement for a full-time DBA to keep it running at peak efficiency. Unfortunately, DB2 on any other platform (e.g., Windows, Linux, AIX) isn't as self-maintaining as it is on the i5. Thus, the biggest advantage DB2 offers to the i5 user wanting to implement a DBMS on another platform is the ease of migrating databases between platforms.
On My Radar
Why consider a different platform? Here's one reason: mobile computing. The availability of PDA-sized devices having respectable amounts of horsepower and RAM are opening some great possibilities for mobile applications. I've always been fascinated by these devices, but their limited resources dissuaded me from actually doing anything with them. Now, they're on my radar again. And if PDAs are too small for the job, there are laptop computers, which can effectively replace most desktop computers. Battery life, formerly a sticking point, is now into the multi-hour range, compliments of the superb power management and high-capacity batteries being included with current laptop models.
Most of the mobile applications that I'm contemplating require some kind of DBMS. My options run the gamut from IBM's DB2e (DB2 Everyplace) to one of Microsoft's offerings. My objections to either of these choices include that they may be tied to specific operating systems (the latter more than the former) and that I'd have to deal with the complication of loading the DBMS software onto every mobile platform that I want to deploy, PDA or laptop. And, of course, there's the license aggravations that come with proprietary software—always a turnoff in my mind.
Some Kind of Sick Joke
Given that I do the majority of my development in Java, I wanted a DBMS that I could deploy just like any Java application. Could I find a DBMS written in Java? As it turns out, there are some outstanding choices that are powerful and have the flexibility to run on any machine with a Java Virtual Machine (JVM) and modest memory resources.
"Hold on now, Barry," I hear you say. "Java for a DBMS?" I have always held the view that to be blazingly fast, a program must be compiled. The first release of Java certainly didn't do anything to dispel that notion. My first impression of Java program performance was that it reminded me of the coffee that Lisa Douglas used to make on the old TV show Green Acres. If you don't remember (or are too young to remember), it poured out of the pot like syrup. All I remember about my first Java experience was thinking that it had to be some kind of sick joke; it was that slow! That was then. Not only has the hardware become so much more powerful, but the JVMs produced by IBM and Sun run Java code at near-native speeds. Thus, a DBMS written in Java is not as far-fetched as it might seem. Certainly a Java-based DBMS will be able to handle the load presented to it by a mobile application, but they are capable of much more.
At the top of my list is that the product must be available under an acceptable open-source license. If I wanted licensing hassles, I'd buy a proprietary product.
I already mentioned that I want the DBMS to be Java-based, if at all possible.
I am extremely interested in a prospective selection's conformance to the SQL standard. While Hibernate (an object-to-relational tool) can help mask variations in SQL syntax, I'm most impressed by software that conforms to published standards. It makes switching out back-end systems a more trivial proposition.
Another big requirement is what I call "functional transparency." By that I mean that my typical applications are client/server apps that connect to the i5 DB2 database, so whatever I use should give me the same "feeling." I give extra points to Java DBMSs that are capable of providing the connectivity to which I am accustomed, without requiring me to use some unfamiliar API for access.
Given these requirements, I explored the options and came up with quite a number of possibilities. The three I settled on meet the requirements that I set forth. I'll discuss each in turn.
This one tops the list simply because of the name recognition. In actuality, IBM open-sourced its Cloudscape database and released it to the stewardship of the Apache organization, where it now has the "Apache Derby" moniker. From the project Web site, I obtained the following feature list:
- Derby has a small footprint, about 2 MB for the base engine and embedded JDBC driver.
- Derby is based on the Java, JDBC, and SQL standards.
- Derby provides an embedded JDBC driver that lets you embed Derby in any Java-based solution.
- Derby also supports the more familiar client/server mode with the Derby Network Client JDBC driver and Derby Network Server.
- Derby is easy to install, deploy, and use.
This sounded exactly like what I was looking for, so I started downloading the "bin" distribution, which contains the jar files, the javadoc, and the documentation. If you wish, you can download just the jar files or the source files from which the jars are built.
While Derby was on its way down, I navigated over to the HSQLDB project Web site. On the front page I found the following blurb:
HSQLDB 1.8.0 final is out. A year of solid development since 1.7.2 brings a more powerful engine that supports data up to 8GB, has better SQL capabilities and runs with greater resilience. HSQLDB 1.8.0 is also the database engine in OpenOffice.org 2.0, soon to appear on millions of desktops around the world.
For those not familiar with OpenOffice.org, it's a serious competitor to Microsoft's Office Productivity suite. Until Version 2.0, it lacked an embedded database engine, such as Microsoft Access, which hampered its acceptance in the business community. OpenOffice.org now has that missing functionality, and it uses HSQLDB to provide it.
After reading the content of the Web site, I decided that if HSQLDB is good enough for the fine folks involved with the OpenOffice.org project, then it's good enough for me. I started it downloading and then went to my next candidate's Web site.
The Mckoi database engine is another that appears to match my requirements. Here's some info from the FAQ:
Mckoi SQL Database is an SQL (Structured Query Language) Database management system written for the Java platform. Mckoi SQL Database is optimized to run as a client/server database server for multiple clients, however it can also be embedded in an application as a stand-alone database. It is highly multi-threaded and features an extendable object-oriented engine.
Mckoi SQL Database started as an internal project and has since evolved from its inception in 1998. The main goals of the project are a code base that is simple to maintain and extend, ease of use and administration, robustness, multiple concurrent access, and performance.
Sounds like a winner to me. I decided to suck up the remainder of my bandwidth and start downloading Mckoi, too.
After testing the three products mentioned, I've come to the conclusion that Java is good...darned good. Since this article is oriented to the technical manager instead of the programmer, I'll summarize my experience instead of boring you with extensive details on my experimentation.
In short, none of the products required any major wailing or gnashing of teeth to get them going. Any competent Java programmer can bring any of these three products online with little effort. There's just nothing remarkable about using these products that requires any special mention. Connecting to the databases via JDBC is no more traumatic or difficult than connecting to our beloved i5. There's really nothing more to do than change the URL provided in the call to the getConnection() method. I can't be any clearer than that. Java just makes the deployment of these three projects if not identical, then extremely similar.
The Java Advantage
There's no doubt about it. Our lives have become increasing more complicated by the advent of the PC and mobile computing. When everything resided on the minicomputer, an update was a fairly straightforward process. Now that we have to distribute our software to platforms that may or may not remain connected to our network, a simple program roll-out or update can become a major project in and of itself.
Software products that require a number of different pieces to implement on a single PC, such as what you'd get if you install a proprietary DBMS and then your application's "pieces and parts," are always going to be more difficult and expensive to maintain in the long run than will products that are self-contained. With Java Web Start, you can load the DBMS and your application with a couple of clicks of the mouse and then keep them updated the same way. Consider that you can now easily assemble a browser-based application that uses Tomcat, one of the DBMSs I mentioned, and a JVM—all in the same bundle. You can run Tomcat and the DBMS as server processes, or you can embed them in your application for the easiest-of-all-to-deploy application. The possibilities are endless! If you really wanted to, you could even run them directly on your i5! Who said that the only DBMS for i5 is DB2?
That's all for this month. I hope that you keep these products in the back of your mind. I'm not deluded enough to think that they'll ever completely supplant DB2, but I am sure that they have a place and that you'll eventually find a project in your own shop where they'd be useful. While you're contemplating the possibilities, I'm going to start looking over the PDA brochures. I just wish picking the hardware could be as easy as picking the software was....