How to: Select a Mobile Database
by Jim Geier

Back to Tutorials

When developing mobile applications, you need to store data, sometimes lots of data, on client devices. With batch applications, this is a requirement because users will infrequently synchronize with the server. You can slide by with not storing data on the client device with wireless applications, but sporadic loss of connectivity due to RF interference and spotty coverage causes disrupts use of the application. Consequently, maintain data on the client device to allow continual access to applications. 

The current database tools enable you to easily replicate data on the mobile device. The client devices and server databases remain in synch, making it possible for users to continually use the mobile application. The need for this feature is what sets mobile systems aside from traditional wire-based solutions. 

Avoid Flat Files

Unfortunately, many mobile software developers store data on the client device in flat files. This makes applications run very slow. 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 speed increase in my price marking applications. By using effective relational database design rules, as with any other applications, relational databases also significantly improves 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 generated a requirement 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 focus on choosing a database that works on a wide variety of platforms. Portability is needed in this case to avoid the need for supporting multiple versions of the software, which can be extremely costly. This became apparent when a company that I was working for decided to productize demo software that I’d written for PalmOS device 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. 

In order 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 as compared to the costs of supporting multiple software versions. Other mobile databases, such as IBM DB2 Everyplace and Oracle9i Lite also have broad platform support. 

Session Persistence Increases Usability

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

It’s beneficial 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 sync cradle or a wireless phone or PDA loses connection with the server database, use of the application continues 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 ponder 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. This is paramount when disclosure of information results in potential damage or loss to a company. For example, a financial institution sending credit card numbers over a wireless network better pay close attention to security. Theft of the card numbers could be easy using freely available sniffing tools unless the application implements encryption.

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, such as Ethernet, 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 500KB of memory. The Sybase iAnywhere UltraLite database, for instance, only needs 150KB of space. PointBase does even better with needs for only 45KB. 

This maximizes storage area for important things, such 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. The days of needing to pack 1.5MB database application software into a small mobile device are over. 

Connection Protocols Make a Difference

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

Availability of standard connection, such as ODBC and JDBC, is 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 open database connectivity interfaces run slower than proprietary connections.

Development Tools Make Life Easier

The availability of tools impacts the decision of a database. In general, tools for enterprise databases are more widespread than for mobile applications. However, some mobile vendors have pretty good utilities. For example, iAnywhere supports all leading development tool environments, such as Java, Sybase PowerBuilder, Microsoft Visual Basic, Visual C++ and 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 lots of 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 Sleepycats’ 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 lots of 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 lots 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. Another plus is that the relatively wide distribution of open source solutions has been under technical scrutiny of many software developers as compared to 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 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

In order 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. This would be familiar grounds with 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. 

Questions? <<Contact the Author>>

Back to Tutorials