Distributed Data Practice

Centralized Data Architectures

There are four dominant models today for where application data resides:

• In a file on a local computer.
• In a shared file on a shared computer drive.
• In a shared database on a central database server.
• In a shared database on a central mainframe.

What all of these approaches have in common is that the data is in ONE place. Of course, this simplifies things immensely for the application developer, but the question is: Is it always best for the data stake-holders (the data producers and consumers)? The clear answer is "No," but until recently technology has made it unrealistic for most projects to consider the distributed data architectures that applications called for.

Let us hasten to add that the Internet has not made this problem disappear. The dominant data distribution model following today's Intranet or Internet approaches is simply a new way to access data shared on a central computer. However, the Internet has advanced the communications infrastructure, one key requirement for building truly distributed databases.

Another key requirement is native support for data replication from the leading database servers, and finally, at long last, we have this, albeit in different ways for each vendor.

Controlled Data Replication

Since we have long recognized the value of truly distributed databases for certain kinds of applications, we already have significant experience in building such applications:

• We used Oracle 8i Enterprise to create a fault-tolerant distributed database system by replicating data in near real-time between a central database and a primary and backup database at each branch location. This both allowed each location to operate independently and at very high speed against its own local database or, if necessary, its backup database while at the same time creating a consolidated central database that both acted as the distribution hub in the replication scheme and permitted consolidated data analysis, reporting, and backup.
• We used Sybase SQL Anywhere to develop a proposal generation system distributed to 14 regions with 18 offices across the country. Any sales representative in any office can generate a proposal, and all proposals in a region are shared with other offices within the region, and all proposals flow to headquarters. Meanwhile all data entered at headquarters flows to the appropriate offices.
• We developed a system for sharing databases between our development team in our offices and on-site management consultants using replication over e-mail links.

As anyone with experience in building distributed database systems knows, a successful project begins with a carefully architected data model that reflects the slices of data that will be distributed and where users will be able to read, update, delete, and insert data. These considerations affect the table structures, key definitions, security model, and so on. In working with us on these applications, you can be assured that, because of our experience, we will be able to anticipate many of the issues that can otherwise transform a distributed application from "write once, deploy everywhere" to "write once, debug everywhere."