Databases Reference
In-Depth Information
and let users share data files. Another component that you will commonly see
is a database server.
12.1.2 Understanding Data Configurations
The configuration that first comes to mind when discussing database applications
is the traditional client/server configuration. Data is located on the database server
supporting applications running on the client or, in a multitier application, an
application server. However, this is not the only data configuration you might
encounter, and even in a client/server configuration, you may have data in loca-
tions other than the database server.
In a client/server configuration, there are two computer types involved, the
client and the server. Processing requirements are split between the computers,
and components of the database application are often running on each. Data
flow is easy to track. Say that someone at a client computer wants to query the
database at the server. The query is entered at the client, and the client com-
puter performs the initial keyboard and screen interaction processing, as well as
initial syntax checking of the query. The system then ships the query over the
LAN to the server where the query is actually run against the database. Only the
results are shipped back to the client.
This becomes a
two-tier approach
when you not only have applications at
the client but also locally stored data, as shown in Figure 12-1. Software has
been developed that makes the location of the data transparent to the user at
the client. In fact, this functionality can be built into your database applications.
In this configuration, the user issues a query at the client, and the software first
checks to see if the required data is on the PC's own hard drive. If it is, it is
retrieved from the hard drive, and that is the end of the story. If it is not there,
then the software automatically looks for the data on the database server.
This two-tiered model is typically discouraged for several reasons. Data
located on the local hard disk is often difficult to share in an environment likely
implemented to promote data sharing. The data is also more difficult to secure,
maintain, and recover in case of errors. Administration and maintenance falls on
the user and often never gets done. You might use this model as an interim solu-
tion while migrating to a centralized database, but it should not be considered
a long term solution.
In an even more sophisticated
three-tier approach,
shown in Figure 12-2,
if the software doesn't find the data on the client PC's hard drive or on the LAN
server, it can leave the LAN through a gateway computer and look for the data
on, for example, a large, mainframe computer that may be reachable from many
LANs. As with the two-tier approach, this is often considered a transitional con-
figuration. It could also be used as a way of justifying the continued existence
and support of a mainframe computer as a very large, very fast (and very expen-
sive) data store supporting the PC database.
