Java databases get small
db4o, PointBase offer relational, object-oriented options for getting data to PDAs
Perhaps PointBase’s most interesting capability is its remote load/unload feature, which allows a PointBase client to talk to a PointBase server over HTTP and exchange SQL scripts. Consequently, remote loading/unloading is a clever way of transmitting not only data but code, too, from point A to point B via HTTP. If the client is a PDA running J2ME, then remote loading is a quick-and-easy way to create a new database on the PDA and load it with data without building a midlet middleman.
PointBase excels at jamming a lot into a little. It does an unparalleled job of creating an RDBMS environment that makes even programmers of large scale desktop systems feel at home.
db4o provides a pure object-oriented database system that takes up about 250KB of space, brags of benchmark tests that suggest speeds on par with larger and more elaborate databases, and uses a query mechanism that is well off the beaten path.
After testing db4o 2.9, there’s no doubt that it is fast. And, db4o is straightforward -- just link to the library and start writing your code. In comparison, PointBase’s many tuned configurations allow you to somewhat tailor an app for the target, but also provide more choices and therefore more decisions to make.
db4o is not specifically for PDAs, but generally speaking, it will run on any device that supports at least JDK 1.1.x. -- the small size and good performance make it a good fit for mobile devices.
In db4o, objects are stored to, retrieved from, and queried within an objectContainer, which is an object representation of the database. Persistence is not transparent in db4o; you must explicitly store and retrieve objects from the database before manipulating them, adding an extra step to the application creation process.
The db4o API includes methods for controlling the depth at which object trees are read and written. You don’t have to do anything special to classes whose objects will be stored in the database beyond ensuring that they are serializable, but you do have to get used to db4o’s unusual method of data access.
The db4o query system uses a variation of QBE (query by example) and supports two flavors of QBE, old and new.
The older QBE starts with a template object of the class of database objects you wish to query; fill the fields of the template object with values that you want matched and execute the query on the objectContainer to receive a collection object with your query matches.
This older method is a simple query mechanism with painful limitations -- it can only perform equivalence queries. It cannot, for example, create a query to retrieve all Employee objects with Salary fields greater than 60,000. In addition, the only way to omit a field from the query is to set it to Null or, for numeric fields, zero.
So why use the older version? It’s easier to work with; plus, it allows backward compatibility, and you can mix the old version with the new version without having to change the structure of the database -- and that’s a good thing.
The newer query method is called SODA (Simple Object Database Access). The SODA query mechanism is also a kind of QBE, but with embellishments that eliminate the older format’s restrictions. You still begin by creating a template object, but with SODA you ornament the template with constraint objects that describe how the comparisons should be made for each field.