Synchronization Development Options

Database Development Options

Now that we have shown some of the benefits of including persistent data storage in your mobile applications, it is time to take a look at the options available for implementing this functionality.

Several factors will influence which method you decide to use. They include the following:

• Required features. Read the features listed earlier. Which are important to your particular application? A few key ones are performance, data storage capacity, transactional capabilities, operating system support, and tools integration.

• Application complexity. How complex is the application's data structure? Does it require relationships between data sets? What forms of data manipulations are required?

• Available resources. Such resources include both financial and development resources. Often a trade-off occurs between the cost and functionality. In addition, consider the internal development and maintenance costs versus the costs of a commercial solution.

• Size of deployment. The number of seats being deployed can have a big impact on your decision. The per-seat cost of developing an in-house solution is higher for smaller deployments. At the same time, the development effort can become much more complex when building an in-house solution that has to support a large number of users. Determining the point at which it becomes more cost-effective to build instead of buy has to be determined on an individual basis

• Support for standards. Is a proprietary system suitable for your corporate needs, or do you require support for standards such as SQL, ODBC, and JDBC?

• Enterprise integration. What kind of enterprise integration is required? Many of the commercial systems come with built-in database synchronization capabilities that will work over a variety of protocols. Does your application require this, or would it be overkill?

As you read the options available, you will want to weigh the pros and cons of each solution against the requirements of your particular application. This decision will have both near-term and long-term consequences, so be sure to dedicate the appropriate effort to it.

Proprietary Storage

All of the leading mobile operating systems include a form of local data storage. These data storage systems are typically flat-file databases with limited features and storage capacity. The interface to these databases is most commonly at the API level. Let us take a look at how data is stored in each of the leading operating systems.

Palm OS

Any kind of persistent data storage on the Palm OS is contained in a flat-file database. This type of data includes both applications as well as user data. Two kinds of database systems are available: record database and resource database. Each is composed of blocks of memory that can contain any application-defined data. The only difference is the size and contents of the header for each of the objects. In general, record databases are used to store application data, such as contact lists. Resource databases are used to store the application code and user interface objects. For our purposes, we are going to concentrate on the record database, since the resource database is mainly used for managing applications, not user-defined data.

As the name indicates, a record database stores records of data. These records are essentially segments of memory that are part of the storage heap of the Palm OS. Each database contains a database header that describes the database, AppInfo and SortInfo blocks, and the record list. Both AppInfo and SortInfo are optional blocks that describe the application information and sorting information, respectively. Figure 9.1 shows the logical record database layout.

Figure 9.1: Logical layout of the record database.

Within the header, various fields describe the database name (which is a 32-byte string), its attributes, the last modified date, the creatorID, the AppInfo, the SortInfo, and many other items. The header ends with a record list, which has its own header, followed by the record entries. Each record entry references the location of the actual data for the record and contains the attribute and ID information for that record.

From a programmer's perspective, the Palm DB is a quick and easy way to add persistent data to an application. To read or write data, the Palm OS provides functions that can be used to convert data into or out of Palm database formats. (Note: Detailed information on these functions is available in the Palm OS "Programmer's API Reference," which is available at www.palmos.com/dev/support/docs/palmos.)

When using the Palm database for your applications, keep in mind that it does have some limitations. First, the application programmer is responsible for database creation and maintenance. This means that within your application code you will have to use the Palm OS API to open, close, and access the data in any way. In addition, you will have to manage the code to create new records, access or modify them, or remove records. If you require additional functionality, it will have to be created by the programmer.

Second, the Palm database is a flat-file database, with all the limitations discussed earlier in this chapter. The main issues are that the Palm database limits the complexity and size of the data storage capabilities and does not have support for transactions. This may not be a factor for simple applications, but it can be a major limitation when representing a portion of an enterprise system on a handheld device.

The final limitation relates to enterprise integration. Palm databases do not come with very robust synchronization capabilities. You can synchronize blocks of data using HotSync, but this capability is often quite limiting in the enterprise space, where a companion PC is not always available and the data integration is often directly to an enterprise RDBMS. In these cases, you are required to write your own data synchronization conduit. This effort will involve creating your own data synchronization layer, which is not a trivial task. (More on information data synchronization is available in Chapter 10, "Enterprise Integration through Synchronization.")

Windows CE

Windows CE contains a built-in database system in the form of its object store API. It is a flat-file database geared at application programmers, to enable them to include persistent data storage in their Windows CE applications. The database is physically located in what is referred to as the object store, a portion of a device's memory allocated by the operating system for persistent storage of files, the Windows CE Registry, and Windows CE databases.

One advantage of this flat-file database is its ease of use. By using the provided API functions, you can add and remove records, search for a particular record, and sort the records based on four different columns. Another helpful feature is the support for timestamps as a data type. This allows the programmer to see if the data has been altered by another application since its last use. The API also includes functions for finding records. These include the FirstEqual, NextEqual, ValueGreater, and ValueSmaller methods, providing conditional search functionality without much extra programming.

Similar to the Palm database, the object store API has some major limitations for more advanced applications. The first is that it can reside only within the device's RAM, meaning it cannot be placed on an auxiliary storage card. This limitation can pose problems for applications that are shipped on PCMCIA or Compact Flash memory cards. In these cases, before the application can run, the database will have to be written to the device's built-in RAM.

Although flat-file databases work well for simple applications or those with mainly static data, they can introduce performance problems for more complex applications. When searching for a specific set of data or attempting to sort data, extra commands and I/O are often required, thereby inhibiting performance. This will become especially noticeable with large data sets.

As with other flat-file solutions, database synchronization with Windows CE object store is also an issue. You are left to develop your own synchronization routines. As discussed in the Palm OS section, this undertaking can require a significant amount of effort to implement.

Symbian OS

The DBMS in the Symbian OS is significantly more advanced than that in either the Palm OS or Windows CE. Rather than using a flat-file database structure, Symbian OS has implemented a relational database. This means you can have multiple tables in the same database, allowing for more complex schemas. In addition to making the storage capabilities more advanced, Symbian has also added data access through a subset of SQL, as well as using C++ APIs. This too provides a more approachable way to interact with the Symbian DBMS.

For most of the common database commands that you will require, such as opening and closing the database, creating tables, creating indexes, and querying data, you have the option of using either SQL or the C++ API. In most cases, the SQL code is more efficient than using the C++ API, with the exception of inserting rows of data. In this case, using the C++ API provides better performance, especially on large amounts of data. Overall, incorporating the built-in DBMS into your applications will require a considerable amount of custom code.

One of the other nice features of the Symbian OS DBMS is the support for transactions. When database changes occur within a transaction, all changes can be undone if something goes wrong during any part of the data manipulation. This is an important feature when you are modifying data in more than one table, ensuring that internal references remain intact.

As with the other built-in databases, the Symbian OS DBMS also has some limitations. For one, the API is only available in C++, limiting access to the other supported programming languages such as Java. This can be a fairly significant limitation as it is expected that Java and other high-level languages will be frequently used for Symbian OS development. Second, even though it is a relational database, it does not offer functionality that is normally found in commercial products. For example, table joins are not supported. This means that you cannot select, insert, or update data from more than one table in a single statement. Finally, there is the synchronization issue: With this database, too, you are required to implement your own synchronization support, which as explained for the Palm OS and Windows CE databases, is a significant challenge.

J2ME

The Mobile Information Device Profile (MIDP) of J2ME provides a persistent storage mechanism called the Record Management System (RMS). The RMS is a set of Java classes for storing and retrieving simple sets of data. The storage takes place in what is called a RecordStore. Each RecordStore consists of a collection of records that are stored in nonvolatile memory, meaning they are persistent. Internally, the data is essentially stored as a byte array.

The MIDP applications that access the RecordStores are called MIDlets. These MIDlets can be grouped together for deployment into MIDlet suites. Each MIDlet suite has its own space for RecordStores; no MIDlet suite is permitted to access other MIDlet suites' RecordStores. That is, there is no mechanism to share RecordStore data between MIDlets in different MIDlet suites. So, if you want to enable more than one MIDlet to access the same set of data, the MIDlets in question have to be in the same suite.

Each RecordStore can be given a name, which is case-sensitive and has a maximum length of 32 Unicode characters. There are not many naming restrictions, other than that two RecordStores within the same suite cannot use the same name. Within the RecordStore, each record is assigned a unique ID. These IDs are managed by the RMS and are autoincremented; thus, the first record will have an ID of 1, the second an ID of 2, and so on.

The application programmer is responsible for managing the RecordStore. There is a set of APIs to open, close, insert, delete, and move through the records. More advanced classes, such as RecordComparator and RecordFilter, allow you to compare two records and filter records, respectively.

As you can see, the MIDP RMS is a very simple data storage mechanism, for limited amounts of data. As a developer, you are responsible for managing the RMS as well as for implementing any synchronization capabilities that may be required.

For other J2ME profiles, commercial database solutions are available. These are discussed later in this chapter.

Proprietary Storage Summary

The leading mobile operating systems all have a built-in form of persistent data storage. The capabilities of these databases vary, but they all are best suited for simple applications that do not require large amounts of data or have complex data structures. If this is the type of application you are building, then these databases offer you a quick, lowcost way to incorporate data storage into your application. You do not have to worry about licensing fees, because the database is part of the operating environment.

If you are building a more complex application, one that has more demanding data storage requirements, these databases are probably not the best choice. As mentioned before, when the data sets become large, these databases suffer from poor performance. They also do not offer many of the key characteristics that are required for many corporate applications. While they all have low resource requirements, they typically do not provide the security, data integrity, support for transactions, scalability, support for standards, or data synchronization capabilities that many solutions require.

One of the final points to keep in mind about all of these solutions is that they are very specific to the given operating system. If you are planning on deploying your application to multiple operating systems, you will incur additional development and maintenance costs using these solutions, as you are essentially working with a different database for each operating system. Everything about how you store and interact with the data is OS-specific, requiring a significant amount of additional work to port the application to another operating system.

Custom-Coded Databases

If the built-in databases do not meet your needs, you always have the option of creating your own database. In this scenario, you can create as simple or as complex of a database as your application requires. If you are looking for basic storage, but are not interested in the built-in databases due to their proprietary nature, you can create a simple flat-file storage mechanism that can work on many platforms. On the other hand, if you require complex data storage with relational database features, you can hand-code this solution. In most cases, this comes down to a "build versus buy" decision.

Companies face a predicament when they come to the conclusion that the available commercial solutions do not meet their needs for one reason or another. It could be because of cost, features, or because of anticipated performance issues. In any case, they have to make a decision whether building a database in-house will result in longterm benefits. This may not be an easy decision to make.

By building a custom database, you can ensure it has all of the features that you require. If you require a relational format with referential integrity, you can build it into the system. At the same time, to maintain a small footprint, you can omit any extra features that may not be required. When it comes to performance and scalability, the onus is again on you. This is sometimes preferable, as you can ensure that the applications run as expected; that said, development and testing often end up being very timeconsuming. Some of the other database features that you may have to custom-code include indexing capabilities to maintain performance, referential integrity to maintain internal data consistency, data-access APIs or SQL support, memory management, and file management, to name just a few. These features alone are often enough to prevent making an in-house solution feasible.

If you require enterprise data integration, you will have to consider building a synchronization layer into your solution as well. This involves building client-side as well as server-side code that can transfer data between your device and back-end server in such a way that you do not lose any data. (More information on what is required in a synchronization solution can be found in Chapter 10.)

Before you start to build a custom solution, make sure that you are aware of the challenges that lie ahead so you are adequately prepared. It is no secret that building a custom database will require significant resources. This is true not only for the development stage but also for the maintenance stage. Remember, mobile operating systems change constantly. Possibly you will have to port your database to new operating systems and new versions of existing operating systems. Each port requires additional development and testing resources to ensure it operates as expected. These cautions are not meant to dissuade you from creating a custom database but rather to make you aware of the effort that will be required.

Of course, there are times when a custom database makes sense. If you are targeting an operating system that is not widely supported by commercial solutions, it may be the only way to get the functionality you require. If you have very specific data storage requirements, which are not addressed by commercial mobile databases, you may find building a custom solution to be to your advantage. These are just two scenarios for which building an in-house solution is beneficial. Just remember that building and maintaining mobile applications is challenge enough; coupled with adding the database, it becomes more so. So if you are contemplating building a solution in-house, research the solutions that already exist to make sure you use your resources to the maximum.

Commercial Relational Databases

Relational databases not only lead the enterprise database market, they are the clear leaders in the mobile market as well. This is largely due to the fact that many of the mobile offerings are from enterprise database vendors. These companies provide a variety of SQL-based solutions with a wide range of capabilities. Some offer key features such as referential integrity, support for indexes, and transaction support, while others do not. Some have open support for operating systems, synchronization integration, and programming languages, while others are more limited.

The point is, when it comes to mobile database implementations, all commercial databases are not created equal. In this section, we examine the leading vendors, summarizing their offerings to give you a place to start for evaluating which technology is best suited for your mobile applications. (Note: The vendors are listed in order of marketshare.)

Note 

This book only describes support for mobile operating systems. Delving into support for desktop environments is outside the scope of this book.

Sybase/iAnywhere Solutions

Product	Sybase SQL Anywhere Studio
URL	www.ianywhere.com/products/sql-anywhere.html
Mobile OS support	Windows CE, Palm OS, Symbian OS, Linux, Java

Key Features:

• Full-featured Adaptive Server Anywhere (ASA) database for desktop environments and Windows CE

• UltraLite deployment for mobile operating systems, providing a relational database with a footprint as small as 50K

• Built-in synchronization to any ODBC back-end data source

• Strong encryption of both the data stores and communication stream

Summary:

To put more emphasis on its mobile and wireless computing solutions, Sybase launched a new company called iAnywhere Solutions. The flagship product offered by iAnywhere Solutions is SQLAnywhere Studio, which includes a variety of mobile database offerings. This product is the established leader in the mobile database market with 73 percent market share (Gartner Dataquest, December 2002). This lead over the competition is a result of iAnywhere's long-term focused commitment to mobile computing, which has enabled them to develop a set of products that squarely meet the requirements of enterprise customers. In the mobile database arena, three technologies are available: Adaptive Server Anywhere (ASA), UltraLite, and UltraLite Component Suite.

Adaptive Server Anywhere is a high-performance mobile database system that offers complete relational database functionality, including stored procedures, triggers, transaction management, record-level locking, and enterprise data replication. All of this is provided in an easy-to-use package that has a compact footprint (around 3 megabytes on Windows CE environments). This version of iAnywhere's technology is available for a variety of desktop and server platforms, as well as Windows CE.

If you are looking for a more compact solution, iAnywhere Solutions provides the innovative UltraLite deployment option. This technology analyzes the database features that your application requires and automatically generates a customized database containing only those features. You can then link this customized database with your application code to create a single executable for deployment. This reduces the complexity of implementing a mobile database solution. For development, you can use common C/C++ development tools such as eMbedded Visual C++ and Metrowerks CodeWarrior. If you are more interested in Java, iAnywhere also offers a pure Java version of the UltraLite database that allows you to develop with any Java development tool and deploy to any device with a Java VM.

In addition to the application-specific version of UltraLite, iAnywhere Solutions also has a more generic relational database for the same operating systems. This technology is called the UltraLite Component Suite; it provides interfaces for development using AppForge, Visual Basic, ActiveX controls, and Java, in addition to the C++ tools mentioned earlier.

On the synchronization side, iAnywhere Solutions offers its MobiLink synchronization server that provides direct, bidirectional synchronization to any ODBC data source, including Sybase, Oracle, Microsoft, and IBM. The synchronization rules are stored in the back-end database to provide a high level of customization capabilities. Both wireless and wireline protocols are supported for synchronization, including HTTP, TCP/IP, and common conduits such as HotSync and ActiveSync.

For security, iAnywhere provides 128-bit strong encryption of the communication stream as well as the data stores themselves.

With their wide platform support and open synchronization capabilities, the mobile database solutions from iAnywhere Solutions are well suited for companies that require a flexible solution that can integrate with heterogeneous back-end databases.

IBM

Product	DB2 Everyplace
URL	www.ibm.com/software/data/db2/everyplace/
OS support	Windows CE, Palm OS, Symbian OS, Linux, Java

Key Features:

• A relational database management system with a footprint as small as 150 KB

• Support for a wide range of mobile operating systems

• Synchronization to a variety of back-end data sources via IBM DB2

Summary:

IBM incorporates three components in its DB2 Everyplace Enterprise product: a small relational database, a synchronization server, and a tool to develop smart client applications for the Palm Computing Platform and Java. Both native versions and Java versions (through IBM's acquisition of Informix) of the database are available. DB2 Everyplace is a relational database management system with a footprint as small as 150 KB. This RDBMS is composed of the default libraries and the database engine itself. The main goal of DB2 Everyplace it to provide a local data store on the mobile device while attempting to keep many of DB2's enterprise features. Some of the included features are SQL support for adding, deleting, and updating data. Missing is support for transactions, which is notable for many corporate developers. DB2 Everyplace implements a subset of the SQL 99 standard, DB2 Call Level Interface (CLI), Open Database Connectivity (ODBC), and Java Database Connectivity (JDBC).

On the development side, IBM offers its own development tool called Mobile Application Builder for Palm OS and Java applications. Mobile Application Builder offers a graphical rapid application development environment with wizards to aid development. DB2 Everyplace also integrates with Visual Basic, C/C++, and Java development tools.

For synchronization, the DB2 Everyplace Sync Server provides bidirectional synchronization from DB2 Everyplace to DB2 Universal Database. Once the data is in DB2 Universal Database, it can then be transmitted to other ODBC data sources, such as Oracle, Sybase, and Microsoft, by using adapters. The synchronization server is implemented as a Java servlet, so it can be hosted in any servlet engine, although it does work best in IBM's WebSphere application server. Being a Java servlet, the synchronization is HTTP-based, and works for both wireless and wired networks. SyncML is the synchronization protocol used by IBM for its data transfer. (For more information on SyncML, see Chapter 10.)

With its broad platform support and small footprint, DB2 Everyplace is well suited for a variety of mobile applications. However, the enterprise integration is somewhat complex in that it requires DB2 Universal Database as an intermediate step before interacting with other data sources, so it may not be ideal for companies that do not currently use DB2 Universal Database.

Oracle

Product	Oracle9i Lite
URL	www.oracle.com
Mobile OS support	Windows CE, Palm OS, Symbian OS

Key Features:

• Lightweight relational database that resides on the mobile device

• Centralized Web management console to manage users, data, applications, and security

• Handles both data and application synchronization

• Synchronization with Oracle enterprise databases

Summary:

The Oracle9i Lite database is built upon the Oracle9i Database and Oracle9i Application server technology. It provides a lightweight relational database with a feature set aimed at being comparable to the Oracle9i database server. It incorporates other technologies (such as Web-to-Go and Mobile SQL) into a single product. This streamlines the installation and configuration procedures, breaking them into two groups: Oracle9i Lite Mobile Development Kit and Oracle9i Lite Mobile server.

The Mobile Development Kit incorporates a set of tools and APIs, along with sample code, to accelerate the development of Oracle9i Lite database applications on mobile devices. At the core of the product is the Oracle9i Lite database. It is a general-purpose database with support for ODBC and JDBC connectivity on all platforms using common development languages such as C/C++, Visual Basic, Satellite Forms, and Java. For Java development, you can take advantage of Oracle's lightweight JDBC driver from your Java clients, although the Oracle database itself is not written in Java.

As to the Oracle9i Lite footprint, it is considered more of a middleweight than a lightweight database. On Windows CE, for example, the combined memory required for the supporting files and engine is close to 5 MB, and this does not include the database itself. On other platforms, the footprint can be as low as 1 megabyte, which is still not small compared to other offerings on the market. In addition, the installation process and feature set vary from platform to platform, so there is no single solution for all mobile devices.

One of the unique features of Oracle9i Lite is how it manages mobile applications. The Oracle Mobile Server is an extension of the Oracle9i Application Server, making it possible to deploy, manage, and synchronize offline applications from a central console. Rather than having a separate engine for application management, Oracle has incorporated this capability directly into the database. This allows you to synchronize both data and applications from a single console. Unfortunately, the application deployment and management is available only for Win32 clients.

When it comes to synchronization, Oracle does not use standard interfaces such as ODBC or JDBC. This means that you can only synchronize Oracle9i Lite clients with Oracle databases. This is fine if your organization uses Oracle technology exclusively; if not, then you will find the synchronization limiting.

Overall, Oracle9i Lite is a capable mobile database platform best suited for companies with homogeneous Oracle server installations.

Microsoft

Product	SQL Server CE
URL	www.microsoft.com/sql/CE/default.asp
OS support	Windows CE

Key Features:

• Lightweight relational database that resides on Windows CE-based mobile devices

• Similar interfaces and data management capabilities to Microsoft SQL Server

• Synchronization with Microsoft SQL Server databases

Summary:

The latest offering in the Microsoft SQL Server family is SQL Server CE. This is a scaled-down version of SQL Server aimed at extending enterprise data to offline applications for Windows CE. It has maintained much of the functionality required for mobile solutions, including a wide range of data types and referential integrity. The database footprint varies, but is typically between 1 and 3 MB.

Microsoft SQL Server CE provides a familiar SQL grammar and a consistent development model and API set to the full-blown SQL Server. Development can be accomplished using Visual Studio .NET using the .NET Compact Framework. These tools and technologies allow developers to use their existing skills to build sophisticated Windows CE-based database applications for a wide range of mobile and embedded applications. In addition, Microsoft supports Remote Data Access (RDA) for accessing back-end Microsoft databases in real time without having to configure SQL Server synchronization.

Synchronization is provided over HTTP to Microsoft SQL Server back-end databases via Microsoft Internet Information Server (IIS). Replication can be performed over wired and wireless LANs and WANs. The communication protocol is well suited for wireless transports. Microsoft has also incorporated support for SSL, giving you the ability to encrypt the data stream to protect sensitive data.

Because the Microsoft SQL Server CE solution is targeted directly at Windows CE devices, and synchronizes only to Microsoft SQL Server, it is suitable only for a very specific market. If you are deploying Windows CE devices that only require integration with Microsoft SQL Server, then this solution should meet your requirements, while giving you a familiar development environment.

PointBase

Product	PointBase Embedded Edition and Micro Edition
URL	www.pointbase.com
OS support	Java

Key Features:

• 100 percent pure Java relational database

• Integration with common Java development tools

• Built-in data synchronization to a variety of back-end sources (Embedded Edition)

Summary:

PointBase is the most recent player to enter the mobile relational database market. Its database products are all 100 percent Java, to provide cross-platform development opportunities. There are two versions that will appeal to mobile developers: PointBase Embedded Edition and PointBase Micro Edition. Both are targeted at mobile applications development, but for different versions of the Java platform.

The PointBase Embedded Edition is aimed primarily at J2SE applications that require multiple database connections from within the same JVM. The Micro Edition works in both J2SE and J2ME environments that require only a single database connection. For this edition, the footprint can be as small as 45 KB; however, it is lacking many features that are required for enterprise mobile applications, most notably, synchronization support.

Both versions take advantage of common development tools, such as Metrowerks CodeWarrior for Java, for rapid application development. For deployment, you can use any JVM on the target platform. The Kada Systems' JVM is often used on the Palm OS, while Insignia Jeode is common on Windows CE. For smart phones and Symbian OS devices, you can use the JVM that comes with the device.

The Embedded Edition offers synchronization via PointBase UniSync. UniSync is a middleware server that allows the PointBase clients to synchronize to any JDBCcompliant back-end data source. Even though it is open to many back-end sources, the synchronization is better if you are communicating to the PointBase Server database. In this case, bidirectional, changes-based updates are supported. For other JDBC data sources, only snapshot updates are supported.

PointBase's main strength is its focus on Java. The concept of developing an application once and deploying it to any mobile device with a Java VM is very attractive to corporate developers. Unfortunately, Java on mobile devices is still relatively immature compared to server and desktop platforms, and users may suffer through some growing pains. However, on some of the more capable mobile devices, creating Java applications is a promising alternative.

Other Database Vendors

When it comes to mobile database technology, a number of smaller companies have capable product offerings. We are not going to take an in-depth look at them here, because the vendors just described hold over 90 percent of the mobile database market. If you are interested in these alternative technologies, review Table 9.1, which lists the company names along with their Web URLs.

Table 9.1: Other Mobile Database Vendors

VENDOR AND PRODUCT	SUPPORTED OPERATING SYSTEMS	WEB SITE
Birdstep Raima Database Manager	Windows CE	www.birdstep.com
DDH Software HanDBase	Palm OS, Windows CE	www.ddhsoftware.com
Land-J Technologies JFile	Palm OS	www.land-j.com
Pervasive Pervasive.SQL	Windows CE	www.pervasive.com
Syware Visual CE	Windows CE	www.syware.com
Thinking Bytes ThinkDB	Palm OS	www.thinkingbytes.com

Conclusions

Proprietary databases provide a quick, low-cost way to implement persistent data storage in smart client applications. They have tight operating system integration, but often are not cross-platform. They are best suited for simple applications that store small amounts of data in a straightforward way. If your application is more complex, requiring additional functionality, you will want to consider the alternatives.

If you develop a database solution in house, the feature set and other capabilities will be limited only by your developers' skill and your corporate resources. Given enough time and money, it is possible to create an in-house database that matches the capabilities of a commercial product. However, it is unlikely that you will want to make that effort if a commercial solution that meets your requirements is available. Undertaking an in-house project of this magnitude is recommended only when proprietary solutions or commercial products do not meet your needs; for example, if the other solutions do not support the target operating system, if the performance is unacceptable, or if the initial costs are prohibitive for your organization.

Commercial database systems provide the best features, including built-in enterprise synchronization. Many of these solutions are market proven as well. If cost is taken out of the equation, it is clear that using a commercial database is your best bet in terms of features, performance, and reduced risk, as they support all of the leading operating systems and communication protocols.

When you add cost into the equation, then you must take other factors into account. Keep in mind that total cost includes not just the license fees for the database, but also development, administration, and maintenance costs. When comparing all factors that influence the total cost of ownership, implementing a commercial database system often comes out as the optimum choice.

Tip 

If you decide to use a commercial database in your applications, it is recommended that you get an evaluation copy of the software to assess some of its capabilities that cannot be learned by reading the product datasheets. Items to focus on are ease of use, stability, performance, and deployment complexity.