Peck Tech Designs - Databases: Client-Server Architecture

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.