Click below to see
some references:
 

Databases:  Client-Server Architecture

On a network, one extra-fast, extra-powerful computer is normally a "server". The company database is stored on the server, and all the PCs on the network (called "clients") request information from it as needed.

 

However, even though the hardware is set up properly, it doesn't mean that the database is.


Poor setup:  One centralized shared database

A lot of companies have all the data, screens, reports and programs stored centrally on the server in one database, which is set up to allow multiple users to access it at one time. 

 

Following is what happens in this setup when a user prints a report:

Division of work - One centralized shared database
(a lot of green is bad!)

Client Server Task
Client   Send a request to the Server to get the Report screen listing all available reports
  Server Send the Report Screen to the Client (computer that requested it)
Client   Send a request to the Server for the desired report 
   Server Look up the Report Program to determine which query to run
  Server Run the appropriate query to get the required information
  Server Look up the Report Program to determine how the information should appear
  Server Do any calculations, totals, grouping, ordering that's required
  Server Format the information properly (add commas and $ to some numbers, page numbers, bold/italic, etc.)
  Server Send the formatted information over the network to the Client
Client   Display the formatted report

This creates a burden on:
The server: since the server's CPU does all the report formatting, totals calculations, etc., and
The network: since (1) instead of sending just the raw data, it's sending a fully formatted report, which is considerably more information; and (2) there's much more back-and-forth activity

Bear in mind that if multiple users are accessing the server simultaneously, poor speed is likely to result.  The idea is to move as much processing as possible to the clients, since today's PC's have plenty of computing power, and to have the server do as little as possible.  This is achieved as follows:


Better setup:  Split database

The proper design is to "split" the database into two:
  Name Description Location
"Front end" Programs, Forms (screens) and Reports Client (individual PC)
  "Back end" Data only Server

Note how the server now hardly does anything, and there's only one interaction between the individual PC and the server:

Division of work - Split database
Client Server Task
Client   Display the Report Screen listing all available reports to the Client
Client   Look up the Report Program to determine which query should be run
Client   Send a request to run the appropriate query to the Server
  Server Run the requested query to get the required information
  Server Send the raw (unformatted) data to the Client
Client   Look up the Report Program to determine how the information should appear
Client   Do any calculations, totals, grouping, ordering that's required
Client   Format the information properly (add commas and $ to some numbers, page numbers, bold/italic, etc.)
Client   Display the formatted report

This design, or "architecture", results in a much faster system, since:

  • The Server is only selecting raw information and not doing calculations or formatting;
  • Much less information is sent over the network, 
  • There are fewer requests made between the Client and the Server, and
  • The Client does all the formatting and calculations.


Disadvantage of Client-Server database setup

This approach does result in some additional effort on the part of the network administrator, since every time changes are made to programs (screens or reports), a new copy of the "front end" has to be copied to all the Clients.  It's well worth it, however, because of increased performance (unless your database is very small and your screens and reports are very simple).

Also, with increasingly fast networks and servers, this isn't as great an issue as it once was.

 


Copyright © Rachel Peck 2003 - all rights reserved
Terms and Conditions of use


Home   |  Site Index   |  Skills and Services |  References  |  Introduction to Computers |  Database Concepts |  Links and For Fun  |  About Us  |  Contact Us