Deploying Distributed Databases on Laptops - File Maker

If you’ve decided to deploy all or part of your database on laptops for traveling staff, hold on tight, because the road can get bumpy!

That said, don’t turn away from this option too quickly, either. The benefits of a well-designed distributed database system are significant in terms of cost savings, efficiency, user buy-in, and flexibility. If you have mobile forces be they traveling executives, sales people, service reps, scouts, field agents, or any number of other variations the liberation of going mobile with a full featured copy of your database application nearly always outweighs the challenges. In some cases, this benefit is realized in the ability for remote staff to input data without the need to have fast online connections or to be online at all, for that matter.

In other cases, the saving grace of a distributed system is immediate and reliable access to critical knowledge bases while on the road. Most often, it’s both. If you send someone away with a copy of the database, you’re usually going to need that copy to stay “in touch.” This section is here to help you do that.

First, you must know your requirements: For instance, how frequently must data be able to travel into and out of each distributed copy? What measures are necessary to ensure that reliable data is maintained and that valuable modifications are not lost? The nature of your answers to these and other questions will define whether your job as the developer is a piece of cake or something less tasty. Next, you’ll examine some of the not-so-obvious considerations of a distributed system, like unique IDs, deployment, and database updates. With these topics under your belt, you’re ready to delve into a simple example solution, which you can use to outfit your own system for distribution. Finally, you’ll look at a complex distributed environment and see how SyncDeK, a third party product for FileMaker, can reduce even the most thorny issues to simple tasks.But before you go any further, you need to understand several terms to make sense.

Distributed Database System
A system whereby more than one copy of the database exists in part or in its entirety and is located either on the hard disk from which each user operates or within a local area network available to each user. This can be distinguished from a strictly client-server system, whereby only one copy of the database exists and each user, whether local to or remote from the host computer site, logs in as a client of that host to access and modify the data within.

Here’s what the topology of a three node distributed system looks like:

Distributed Database System

In a distributed system, each copy of the database is referred to as a node. This should not be confused with a computer seat, which is a computer or terminal from which a user accesses a database system. If one of the nodes in a distributed system is hosted in a multi-user environment, each of the users that accesses this node does so from a computer seat.

Central Node
According to most distributed system schemes, one of the nodes is designated as the central or master node, and is tasked with the job of maintaining data integrity among the one or more additional nodes in the system.

Synchronization vs. Replication
These two terms are often mistaken. Strictly speaking, a distributed system can use a form of either or both methods to maintain data consistency among nodes.

According to synchronization, two nodes ensure consistency by comparing all records in each database and ensuring that each record exists in the other node and contains identical content. While a very reliable means of maintaining data consistency, this method imposes many limitations in terms of scalability, speed, and efficiency.

This brings us to replication. By this method, a source node uses one of many possible techniques to determine what activity has taken place in a given period so that a reflection of this activity can be replicated at the target node(s). This method is usually desirable, but requires very reliable means of capture, transmission, and replay of replication instructions. If a database activity isn’t captured, is lost during transmission, or is not successfully carried out at a target node, data consistency begins to diminish.

In Sync
Although this is used to refer to a particular group of male vocalists, this term is used here to refer loosely to two or more nodes having appropriately consistent data. It is not meant to refer exclusively to the method of synchronization (vs. replication explained above, but rather to the effective result of either method.

The following illustration contrasts uni- and bi- directional synchronization:

Synchronization vs. Replication

Uni-directional vs. Bi-directional Replication/Synchronization
Whether replication or synchronization is used, you must also consider whether only one or both nodes should publish local changes to other nodes.

According to uni-directional methodology, only one of the nodes ensures the other has information about its records. If synchronization is being performed, the source node will typically connect directly to the target node and ensure that each record it maintains is present and equal in the target node. If replication is being used, then the source node will either propagate replication changes directly into the database at the target node, or publish these to the node for local propagation.

According to bi-directional methodology, data from each node is compared or published against the other, ensuring that shared data between the two nodes is maintained regardless of which node originated the activity.

Conflict Detection
This refers to the process whereby changes to the same records at more than one node are identified (e.g., a user at Node A modifies the same customer record as a user at Node B).

Conflict Resolution
Having detected a conflict, conflict resolution is the process by which problems are handled. There is a broad spectrum of methods for dealing with conflict resolution from ignoring the problem, to logging it for manual handling, to using rules to conditionally determine which node wins out, to utilizing steps which mitigate the problem by merging the conflicting records.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

File Maker Topics