CST(44)-The Distributed Database Model

Standard off-the-shelf commercial distributed database packages will provide, when they fully blossom, transparent access to data on a network. The distributed database keeps track of the location of data on the network, and it will route your requests to the right database nodes, making their location transparent. To be fully distributed, a database server must support multisite updates using a transactional two-phase commit discipline. It should allow you to join data from tables that reside on several machines. It should also automatically update data in tables that reside on several machines.

Distributed databases make it easy to write distributed applications without having to first decompose your applications. With true distributed databases, the location of the data is completely transparent to the application. The chief advantage of distributed databases is that they allow access to remote data transparently while keeping most of the data local to the applications that actually use it.

  •  They currently do not work in heterogeneous database environments. As a result, you’re locked into a single vendor solution.
  •  They poorly encapsulate data and services. You cannot change a local database table if other sites are using it.
  •  They require too many low-level message exchanges to get work done. Distributed databases exchange messages at the SQL level.
  •  They are very slow over long wide-area networks. Two-phase commits are very expensive in terms of messages sent, and it is difficult to join tables located on different computers and achieve good performance.
CST(44)-The Distributed Database Model Reviewed by 1000sourcecodes on 21:40 Rating: 5
Powered by Blogger.