Agile Object to Relational Database Replication with db4o
Databases can be many things to many people. For some, a database is something that handles enterprise data on a cluster of back-end servers. Others work at the other end of the spectrum and need to gather and store data on small mobile devices such as PDAs or more specialized vertical market devices. Sometimes these devices have a network connection that allows them to talk directly to a back-end server. Often, however, they are partially connected, and need their own local data store.
This is where embedded databases come into the picture. These are databases that can be embedded into applications, rather than running as separate processes. It's not surprising that they have become increasingly popular in the past few years. Most embedded databases are lightweight variants of the traditional SQL database. However, this is an area where db4o, an open source native pure object database for Java and .NET, excels. db4o, which I described in a previous article, has some important assets in this type of environment: small footprint, zero administration, and, as a native object database, the ability to store objects as they are, with no need to define a database schema or map objects to tables. The domain class model itself is the database schema. The simplicity of development with an object database can lead to significant savings in time and effort.
Why Replicate?
There are some potential drawbacks with an object database like db4o. Since data is stored in the form of Java or .NET objects, you can only make sense of it within the application that created it, or with an application that can access the same model classes. You can't just fire an SQL query at the database.
The new db4o Replication System (dRS) now allows you to join together the different worlds of object and relational databases. Based on Hibernate, it provides the capability to replicate data between db4o and relational databases such as Oracle and MySQL. In practice, this can mean you can synchronize data between the local db4o database on a partially connected device and an enterprise RDBMS. It also means that your db4o data becomes available on an SQL-friendly platform for ad hoc access.
Related Reading 
|
dRS also allows such distributed systems to benefit from db4o's schema evolution support. In an agile environment, object models may be refactored frequently. db4o automatically adapts to a changed object model, and those changes can be replicated into the RDBMS.
db4o Replication System (dRS)
db4objects Inc., the company behind the db4o database, has recently released a development version of its new replication solution. dRS can be used in a distributed db4o-based system in a number of ways. Here are some possible scenarios:
- You have many mobile devices that are used to gather data in db4o databases while disconnected from your network, and you need to aggregate the data into a db4o database within a central desktop or server application. You also want to keep the mobile and central data synchronized following updates to either database.
- You need to make the data from the db4o databases available in a MySQL database for processing by a separate tool, possibly for reporting or data mining.
- You want to synchronize the data in your MySQL database with an Oracle database that is accessed by another application--this one sounds a bit strange, as there's no db4o database involved, but it can be done!
dRS provides an object-oriented API that lets you write simple applications to perform these tasks, or to embed the capabilities within your applications. Although db4o supports both Java and .NET, the initial release of dRS is Java-only. However, it can also be used to replicate databases containing .NET objects.
The ability to replicate between native databases is an important feature for db4o in distributed applications in which components are not necessarily able to communicate over permanent or highly available network connections. A db4o database consists of a single, easily transportable file, the contents of which can be made available to applications through a lightweight network server, through a server embedded within the application, or by simply opening the file in a single-user mode. This gives a great deal of flexibility: as long as a replication system can get access to a database file, it can synchronize it with another file or files.
There are other benefits from an object-oriented approach to replication. For example, a replication process often needs to handle conflicts; for example, where objects have been modified since the last replication in two databases that are to be synchronized. Because dRS can work with the actual business objects, rather than a representation of their field values mapped onto tables, it is possible to build the precedence criteria into the business logic within the objects. For example, in a system with customers and salespersons, a customer object might be able to store information to indicate whether that object was changed by a salesperson with "ownership" of that customer. The replication process could then access that information encapsulated in the objects themselves to help resolve conflicts.
From Objects to Tables
Replication between native object databases is interesting, but what is likely to make many people sit up and take notice of db4o is the ability to replicate objects from a native object database to MySQL, or to Oracle, or to whatever RDBMS you might prefer to use. You can develop your application with db4o, but you can access the data pretty much any way you want. If your company has a preference to have all of its data deposited within an Oracle system, you can do it, even if it was originally created by a db4o-based application.
In this article, I'll concentrate on the object-to-relational capability of dRS.This is intended to give you a flavor of what db4o and dRS can do; it is not meant to be a comprehensive guide to all the features of dRS. Along the way, having a close look at the same data in different databases will highlight some of the ways in which a native object database differs from a relational one.
原始链接