Why Data Distribution
Why implement a Distributed Database?
There are several reasons to implement a distributed database environment such as:
- Data Locality
- Mobile Workforce
- Data Subsets
Data locality is the ability to place data near the users. In large enterprises, the work force is located in many locations around the world. In my latest application area, Customer Relationship Management (CRM), these enterprises could have Call Centers in many locations around the world. If they had to connect to a database located at a central site, some of the users would suffer from long delay times due to telecommunication delays. Providing a local database for the users, the performance of the system is improved for the remote locations and because of this performance improvement customer satisfaction is greatly improved.
I know you are thinking that a database replication method as provided by many database vendors could achieve the same means. This is true as long as you live with a serious restriction that these replication products have which is that they only support a single write instance of a database row. This means that if a trouble call is logged in Sydney, it can’t be updated outside of Sydney. In the CRM space, this will cause two common practices to be prevented, Follow-The-Sun (FTS) support and Escalation. In FTS, if a call is logged in Sydney, when the Sydney office closes, the call is moved to another Call Center such as Geneva for continued support. With Escalation, when the Call Center personnel determine that they can’t resolve the issue, they will escalate the call to a higher level of support or maybe to the engineering staff.
Many people in these large enterprises spend most of their time away from an office where they could run an application and perform their work. The salesperson may spend most of his time at customer sites, taking orders, providing technical data and other tasks. It is not always
feasible to connect a laptop to a phone line and dial into the corporate network to enter orders or literature requests. Even if this was possible, the telecommunications latency could cause serious performance problems. With a database in the laptop, the salesperson can enter orders and literature requests into his database and at a later time, dial into the network and send these items to the other databases in the networks. Also imagine if the salesperson has an up to date price list on the laptop. Quotes can be created and edited in an interactive fashion and printed locally.
The example of the Field Service Technician is also interesting in this example. The technician can update the database on the laptop and have the trouble calls that they are to work on the laptop. As these call are worked, the tech can update the calls, order parts and close the calls. At a later time, these call updates will be updated in the other databases.
One issue with the use of laptops is that they usually don’t have the capacity to hold a complete application database. In this instance a means to provide only the useful information from the database will make it possible to have a copy of the application running on the laptop. Limiting the data to the customers that the laptop user supports could do this. It could also be done by limiting the reference data such as parts lists to those of interest to the user. If a salesperson sells printers and supplies, they would not be interested in information on systems and peripherals.
Another reason for data subsets is data security. At AMAT, the application was installed at the customer sites. These customers didn’t want other customers to be able to see any information on. This can be achieved by using data subsets.