19.4. Database servers

The term "database server" is usually used to refer to the entire DBMS based on the client-server architecture, including both server and client parts. Such systems are designed to store and provide access to databases.

Although usually one database is stored entirely in a single network node and is supported by a single server, database servers are a simple and cheap approach to distributed databases, since the common database is accessible to all users of the local network.

19.4.1. Principles of interaction between client and server parts

Access to the database from the application or user is done by referring to the client part of the system. The main interface between the client and server parts is the SQL database language.

This language is essentially the current standard for a DBMS interface in open systems. The generic name SQL Server refers to all SQL-based database servers. Observing precautions in programming, some of which were discussed in previous lectures, you can create application information systems that are mobile in the class of SQL servers.

Database servers, whose interface is based solely on the SQL language, have their own advantages and disadvantages. The obvious advantage is the standard interface. In the limit, although this is not quite the case yet, the client parts of any SQL-oriented DBMS could work with any SQL server, regardless of who produced it.

The disadvantage is also pretty obvious. With such a high level of interface between the client and server parts of the system, too few DBMS programs run on the client side. This is normal if a low-power workstation is used on the client side. But if the client computer has enough power, then there is often a desire to assign more database management functions to it, by unloading the server, which is the bottleneck of the entire system.

One of the promising areas of the DBMS is the flexible configuration of the system, in which the distribution of functions between the client and user parts of the DBMS is determined during installation of the system.

19.4.2. Benefits of Remote Procedure Call Protocols

The above mentioned remote procedure call protocols are especially important in database management systems based on the client-server architecture.

First, the use of the remote procedure mechanism makes it possible to really redistribute functions between the client and server parts of the system, since in the program text a remote procedure call is no different from a remote call, and therefore, theoretically, any component of the system can be located both on the server side and on the side. customer

Secondly, the remote call mechanism hides the differences between interacting computers. Physically heterogeneous local area network of computers is reduced to a logically homogeneous network of interacting software components. As a result, users are not obliged to seriously take care of a one-time purchase of compatible servers and workstations.

19.4.3. Typical separation of functions between clients and servers

In a typical case today, on the client side of the DBMS, only such software works that does not have direct access to the databases, but refers to the server using the SQL language.

In some cases, I would like to include in the client side of the system some functions for working with the database “local cache”, i.e. with the part that is heavily used by the client application. In modern technology, this can be done only by formally creating on the client side a local copy of the database server and considering the entire system as a set of interacting servers.

On the other hand, sometimes I would like to transfer a large part of the application system to the server side if the difference in the power of client workstations and the server is too great. In general, using RPC is not difficult to do. But it is required that the underlying server software really allows this. In particular, when using the UNIX operating system, there are practically no problems.

19.4.4. Requirements for hardware capabilities and basic software clients and servers

From the previous reasoning it is clear that the requirements for hardware and software of client and server computers differ depending on the type of use of the system.

If the separation between the client and the server is quite hard (as in most modern DBMS), then users working on workstations or personal computers do not care what hardware and operating system are running on the server, as long as it copes with the emerging flow of requests.

But if there may be a need for the redistribution of functions between the client and the server, then it doesn’t matter what operating systems are used.