Choosing a Mobile Database

By Jim Geier

When developing mobile applications, you need to store data (sometimes lots of data) on client devices. This is obvious with batch applications where users will infrequently synchronize with the server. Sometimes, you may be able to rely on wireless networking, but sporadic loss of connectivity caused by RF interference and spotty coverage can disrupt the use of the application. As a practical matter, then, maintaining data on the client device is a necessity.

Current database tools make it fairly easy to replicate data on the mobile device. The client devices and server databases remain synchronized, making it possible for users to continually use the mobile application even when disconnected.

Avoid Flat Files

Unfortunately, many mobile software developers store data in flat files on the client device. This makes applications run very slowly. For example, several years ago, I made use of flat files when developing pricing application software for bar-code scanners. At this time, there were no other effective storage options for small, mobile devices.

When "wireless-ready" relational databases became available and reliable, I abandoned flat files. The outcome was an amazing 20 to 30 times speed increase in my price-marking applications. With careful database design, relational databases can also significantly improve data integrity. These improvements made me a firm believer in databases on mobile devices.

Let's take a look at what you should consider when selecting a database solution for mobile applications.

OS Platform a Likely Requirement

In many mobile systems, the platform of the client device will be chosen early in the life of the project. For example, I was developing a solution for a city government that wanted housing inspectors to use Compaq iPaqs when collecting data at building construction sites. This required that the database run on Windows CE. As with this and other applications, the platform is usually a requirement that drives the initial selection of the database.

If application software will be sold as a product apart from the client device, then you will want a database that works on a wide variety of platforms. This reduces the need to support multiple versions of the software, which can be extremely costly. This became apparent when a company I was working for decided to productize demo software that I'd written for PalmOS devices using Satellite Forms. I could continue with developing the product using Satellite Forms, but then I'd need to use other tools for Windows CE and Linux platforms. Satellite Forms is a really good tool for rapid mobile application development, but it only operates on PalmOS.

To simplify development, I decided to use PointBase because it integrates with Java applications and supports a wide range of platforms. With a single database-development environment, I could create one application for all cases. I had to experience a bit of a learning curve, but that was insignificant in this project when compared to the costs of supporting multiple software versions. Other mobile databases (such as IBM DB2 Everyplace and Oracle9i Lite) also feature broad platform support.

Session Persistence Increases Usability

Wired systems generally provide continuous connectivity between client devices and the server. For example, the synchronization process between a PDA and a PC over a USB connection seldom fails. It's a different story with wireless systems, which demand smarter client software.

It helps if the mobile database you choose has built-in data synchronization. This works automatically and compensates for bumps that occur with wireless connectivity. For example, Oracle9i Lite incorporates client-side representation of server data and applications. As a user unplugs a batch device from the cradle, or a wireless phone or PDA loses connection with the server database, the application continues to run with the most up-to-date information in the database. After the client device regains the connection, Oracle9i Lite automatically updates the central server database.

If session-persistence features are not available in your database of choice, then consider including wireless middleware. Middleware acts as a intermediary between the client device and the server. If wireless connections are lost, middleware maintains appropriate communications with the server. This keeps sessions open, and minimizes headaches for users. It also provides necessary synchronization of data.

Security Provisions Protect Data

Security is very important for mobile applications, especially wireless and public solutions. For example, a financial institution sending credit card numbers over a wireless network must pay close attention to security. Freely available sniffing tools make it easy to intercept unencrypted data.

Wireless standards (such as 802.11 and Wi-Fi) offer encryption, but it only applies to the air interface. Client devices encrypt the data before transmission, and the access point performs decryption before forwarding the data to the server. As a result, data sent over the distribution system (whether Ethernet or the public Internet) is sent in the clear.

For mobile applications, be sure to implement complete end-to-end security. iAnywhere, for example, includes 128-bit encryption between the client device and the server. This ensures that any transfer of data is not left open to hackers.

Memory Footprint Matters

Because client devices have limited memory, the mobile database software should fit within a relatively small footprint. Look for databases requiring less than 500 KB of memory. For example, the Sybase iAnywhere UltraLite database only needs 150 KB of space. PointBase does even better at only 45 KB.

This maximizes storage area for such important things as application software and data. In fact, memory footprint is one of the biggest differences between a mobile database and one that runs on a server. You no longer need to allow 1.5 MB for your mobile database applications.

Connection Protocols Make a Difference

In both batch and wireless applications, you must synchronize data between the client device and a server. As a result, ensure that the chosen database works with specialized synchronization services or server products. Discover initially how much customization you'll need to make in order to interface the data.

Standard APIs (such as ODBC and JDBC) are crucial for most applications, especially if you're interfacing one particular vendor's database on the client device to another one on the server. For example, Oracle9i Lite offers support for ODBC and JDBC, which lets companies integrate and migrate to different applications as needs change. Keep in mind, however, that standard connectivity interfaces can run slower than proprietary connections.

Development Tools Make Life Easier

Generally, enterprise databases have better development tool support than mobile databases. However, there are exceptions. For example, iAnywhere supports all leading development tool environments (such as Java, Sybase PowerBuilder, Microsoft Visual Basic, Visual C++, Visual Studio .NET, AppForge MobileVB, Symantec Visual Cafe, Borland Delphi, and Metrowerks CodeWarrior). With this level of support, you can leverage experience in familiar development environments.

Oracle9i Lite offers a Mobile Development Kit, which includes many APIs and sample code that accelerates the development of mobile applications. The Development Kit also offers an effective packaging wizard that ties together all mobile application components (such as executables, DLLs, and images) into a self-executable file that is easily deployed to client devices. Toolkits such as this are essential for getting started on the right foot.

Open Source Tools Offer Flexibility

If you need lots of flexibility, then consider using an Open Source mobile database (such as Sleepycat's Berkeley DB). With this approach, you're not dependent on an outside vendor that may make changes that impact your software. When developing data-collection software for Palm devices, I found myself making several last-minute modifications to the software to accommodate changes made by the database vendor. With Open Source database solutions, you have total control over all changes.

Open Source solutions provide plenty of flexibility, but you're totally responsible for coding and supporting the application. You can, however, integrate a solution such as Berkeley DB into your existing product's build environment in a more familiar way. Also, the relatively wide distribution often means that Open Source solutions have been subjected to more technical scrutiny than comparable proprietary databases.

Management Utilities Ease Support

When selecting a mobile database, keep management features in mind. For example, Oracle9i Lite includes a mobile server control center, which enables fairly good server-side management of the mobile applications and users. After publishing the application, an administrator uses the control center to assign application access privileges to users and views status of client devices. To maximize interoperability with management tools, consider choosing a mobile database supplied by the server-side database vendor.

Something to keep in mind is that Open Source solutions (such as Berkeley DB) don't require management utilities separate from what the existing operating system provides. Berkeley DB uses standard operating system services to perform maintenance tasks such as backups, recovery, performance-tuning, and routine maintenance. This results in a much more integrated solution, which reduces total cost of ownership.

Previous Experience a Deciding Factor

To break a tie between equivalent databases, consider your previous experience with developing database applications. If you've been implementing Microsoft database applications for the past ten years, then strongly consider using Microsoft tools. For example, Microsoft offers SQL Server CE 2.0 that supports the familiar Structured SQL syntax and APIs consistent with Microsoft SQL Server. This would be familiar grounds with a minimal learning curve.

I remember when the only choice for mobile databases was a small start-up company specializing in mobile solutions. The extra time needed to learn a new development environment would always impact the schedule and budget of the project. At least today, the major database vendors (such as Oracle, Microsoft, Sybase, and IBM) have mobile database solutions. It's likely that one of those comply with your previous experience.