Databases are collections of data entries which are organized, stored, and manipulated in a manner specified by applications known as database managers. The manner in which database entries are organized in a database is known as the data structure of the database. Database managers organize information in a database into records, with each record made up of fields. Fields and records may have different characteristics depending upon the purpose and functionality of the database manager. The term “database,” as used herein, describes data entries and associated database managers. Hereinafter, the term “database” is intended to include both data entries and associated database managers.
It is sometimes desirable to synchronize databases. The term “synchronize,” as used herein, refers to database operations, associated with two or more devices, that change the contents of one database so that it matches, or “mirrors”, the contents of the other database. Synchronization may be total (e.g., mirroring all of the contents of a database) or partial (e.g., mirroring a subset of all of the content of a database). A prior art technique for accomplishing this synchronization, sometimes referred to as “slow synchronization” involved comparing each record in each database. It may be noted that slow synchronization many not be capable of partial synchronization. Moreover, slow synchronization is complicated and time-consuming.
Another prior art technique to synchronize databases involves implementing a change log. The change log contains information regarding records which have been operated upon in either database subsequent to synchronization therebetween. The change log also records the time at which a synchronization operation was last performed between two databases, so that changes made prior to a previous update can be ignored. Then, synchronization procedures use the change log to determine what records should be synchronized. This alleviates the burden of synchronizing the entire databases. This technique is sometimes referred to as “fast synchronization.”
One weakness with the techniques may be illustrated with the following example. Suppose mirrored information resides on a first device and on a second device. A change is made on the first device to new valid information. A change is subsequently made on the second device, changing old, invalid data to updated, but invalid data. Typically, a timestamp would be associated with both changes in a change log. When resolving the two changes, the most recent timestamp would be favored. Accordingly, in this example, the change on the first device to new, valid data would not be implemented on the second device because a change was made in the interim (i.e., before synchronization to mirror the valid data).
Because the timestamps play an important role in the synchronization process, clocks in the devices may need to be accurate, aligned with one another, and unchanged. This is not always the case in, for example, mobile devices. Indeed, it is quite common for the user of a mobile device to travel to another time zone and therefore, change the time on the device's clock. This can cause problems with synchronization. In some cases, problems with timestamps can cause devices to ignore changes in the synchronization effort, effectively losing the change.
In addition to the synchronization problems, users may find it tedious, or forget to update databases with new data. For example, a user may update an address book locally, but fail to send updates to acquaintances to inform them of the changed information. Moreover, users who receive updated information may forget to update the contact information or may find it tedious to update information continuously for a large number of contacts. For enterprises that maintain a contact database, this can be particularly time-consuming.