Why Use Java DB For Web Client Storage?
I've been wanting to write about the value of a relational database
(and Java DB in particular) when implementing local storage
in web clients. The announcement of Zimbra's offline support and the dialog on their blog of why they chose Derby over dojo.storage has motivated me to get these thoughts out there.
Why would you
want to use a relational database (and particularly Java DB) for local storage rather than other
solutions, such as the WHATWG API implemented in Firefox 2.0 or
the dojo.storage package
, which provide a simpler key/value storage mechanism?Here are some of the key benefits of using a relational
- Transactions - most relational databases implement
transactional semantics. This means that operations on your data
are done in such a way that they are ACID - Atomic, Consistent,
Isolated, and Durable. Transactional semantics ensure that your
data is not corrupted, lost, or viewed in inconsistent ways. Like
backups, often this doesn't seem important, and then it becomes very
- Queries - one of the key values of a relational model
is the ability to issue dynamic queries over your data set. Without
a relational query engine, you will have to build your own query
- Joins - Joins let you take two tables in a
query and "join" them together to get a view of your data
that looks like a new table. Without this
feature, applications end up being locked in to a particular data
model and it's very difficult to create and manipulate new views
of data. Joins also allow you to avoid duplication of data across
- Caching - Most relational databases implement data
caching for you, bringing significant performance savings. Depending
on which key/value storage API you use, you may find yourself having
to implement your own caching depending on your performance needs.
- Indexes - also called access methods, indexes
allow quick access to data for common access patterns. A key/
value model has a single index you get for free. If you
want secondary indices, you have to build them yourself.
- Well-established standards - Using well-established
standards like SQL and JDBC avoids vendor lock-in and expands the pool
of engineers who will have the skills needed to work on your code
Why Java DB / Apache Derby?
- 100% Java - This means portability. Java DB even runs
on the CDC (Connected Device Configuration) profile of the Java 2 Micro Edition
(J2ME). This means your application will be able to play
in the mobile space if and when that becomes an opportunity for you.
Small footprint - Java DB is a single jar file with a runtime
footprint of 2MB. Using
Pack200 it can be compressed down to 700K. Pretty impressive for a fully functional relational database.
Transactional - Not all relational databases are created
equal. Some trade off size and speed for potential loss or
corruption of data. Java DB supports full transactional semantics.
Embeddable and Zero Administration - Java DB can run embedded
in the same VM as your application (and thus embedded in the
browser's VM too). It also in most cases can be brought up without
any administration - your first connection to the database automatically
boots it up. Recovery and upgrade are also automatic. This is key
when you're trying to provide a solution that is used by consumers
or naive users and you don't even want them to know there's a database
under the covers.
There are lots of situations where a simple key/value storage mechanism
works just fine. It is simple, easy to understand, and you can generally get productive sooner. But when making a decision, look at your current
and future requirements and make sure that key/value is going
to meet your needs.