18th Chapter-delphi Client Server application Development (II.) (1)

18.1.4.1-Local Database interface

The local database is produced by the computer. Dbaseii as one of the earliest and still-used systems is a typical local database.

The data for the local database management system is stored on a local hard drive. The DBMS accepts commands from users or user programs. These commands are typically a system-specific database management language. The command is converted to a simple disk access command and delivered to the file system for processing. The DBMS then receives the data from the disk and processes it.

In a local DBMS application, the database Engine (DBE) runs on the workstation. Figure 18.2 implies that the data is stored on the local drive of the workstation, and that the data can also be stored on the file server in the network. Here the database engine uses typical file I/O calls and logging blocking techniques to read and write data directly.

When the file that holds the data is on a server in the network, the power of the DBMS is the same as the stand-alone case. The network operating system is responsible for managing the server, so for the DBMS, the server is used as if it were a local drive.

When a user issues a command that requests the DBMS to read data in a database, the request is first processed by a workstation (client) network driver, which is responsible for uploading requests from the network to the desired server network file system. The server operating system finds data from the appropriate disk volumes and returns to the workstation driver waiting. Finally, the data is passed back to the DBMS, so that the DBMS uses this data just as it does with locally stored data. The interface in a network situation increases the communication overhead than a stand-alone interface, and normally this extra overhead does not affect the user's response time unless the DBMS requires a large amount of data to be delivered during the peak of network traffic.

Most of the work on the local DBMS is done on the workstation side, and even if the data is stored on the file server, the processing of the data is still on the workstation. One of the main drawbacks of this approach is that no matter how little data the query needs, all the data in the query needs to be uploaded to the workstation through the network, then the workstation is responsible for selecting the data that satisfies the query conditions, it is not difficult to imagine that when several users operate the database simultaneously, the bandwidth of the database network will quickly block.

In this way, workstations are responsible not only for all user interface management, but also for all data processing work. In today's database applications, especially those that are powerful and easy to use, the processing overhead of the user interface is quite large, as in a graphics environment like windows, where the overhead is greater. Upgrading workstations for this purpose is not worth the candle.

18.1.4.2 client/Server data interface

As the server hardware technology is increasing rapidly in the past year, the database has changed in the processing mode in the last five years. Local DBMS gradually gives way to client/server DBMS, especially in large and medium-sized enterprises.

As the name implies, client/server is to spread the processing work to the workstation and server to deal with, the server is not only responsible for accessing the data, but also for the data processing, so that the data sent to the workstation before the query result set, so that in most cases can significantly reduce the cost of network transmission, therefore, Also reduces the burden of work processing, so just care about the user interface processing work.

Another benefit of server processing data is that multiple workstations can benefit when the database engine uses buffering mechanisms in the server. For example, a user queries a data, and when another user wants to query the same data, the results are obtained directly from the server buffer, eliminating a lot of overhead.

The success of a client/server system depends to a large extent on the quality and capacity of the server's hardware. The more users, the heavier the server processing burden, the corresponding server hardware performance to keep up, otherwise it will lead to response time than the local database will be worse results.

Processing work, while workstations are responsible for user interface processing work

The database interface between the client and the server is much more complex than the local type system. It has several conversion levels responsible for the transfer of commands and result sets between workstations and servers. Figure 18.5 shows the details of the client/server database interface.

Client/server front-end applications do not actually deal directly with the database engine. Each client server provides a database communication interface that runs on the front end of the database. These interfaces are also called database Communication APIs, and so on. The workflow of the database communication interface is as follows:

The ① front-end application sends commands to the database communication interface.

The ② interface passes the command over the network to the database engine.

The ③ database engine does work such as querying or updating operations on a service, accessing physical data through a network file system.

The ④ database engine returns the results to the communication interface on the workstation.

The ⑤ front end receives the result from the interface, displays or according to the user request to do other processing.

The client/server model is closer to ODBC than the native DBMS. Because the command sent from the front end to the database and the return from the database to the front-end results are transparent, there is no need to know how the specific delivery mode, the different systems exist: the client/server system in the management of the station and the server communication between the way, will not be compatible with each other. In addition, the lack of ability to read different types of data sources is a problem for local DBMS. These problems have been solved effectively in the IDAPI.

18.1.4.3 Borland Delphi Solution

IDAPI addresses compatibility issues with both the local database interface and the client/server database interface through BDE (Borland database Engine) and SQL Links, as shown in Figure 13.1.

Delphi's database features make it easy to build database applications. These applications have access to local databases such as visual DBASE, Paradox, InterBase Server for Windows, and Oracle, Sybase, Informix, SQL Server, and remote InterBase Server and other client/server databases.

BDE is the core database engine and interconnect software for Borland Company Support Delphi 2.0 Client/server Suite, Paradox for Windows, Visual DBASE for Windows, and so on. BDE provides rich and robust features to support the development of client/server applications.

Provides a unified and consistent application programming interface (API) that supports multiple databases such as dBASE, Paradox, Text, InterBase, Oracle, Sybase and Microsoft SQL Server, and any ODBC data sources. Developers can access different database sites and database formats without modifying the database application:

BDE is an ideal tool for developing client/server database applications where database applications can access both the local database and the remote database

Allow databases to access data sources directly and flexibly

BDE is a high-performance database engine for the Paradox and dBASE file formats

Supports access to data using ISAM (INDEXTD sequential access method) SQL and QBE

BDE is a data integration engine that enhances shared services across different databases. Supports reciprocal transformations of different database formats, such as dBASE and Oracle tables, copying data from InterBase to paradox and even establishing a one-to-many relationship between InterBase and Oracle tables

The BDE query engine provides a consistent query language for SQL,QBE and for collection-oriented access. The ability to support user-defined and access to basic SQL Servers and file-based databases

BDE supports full 32-bit functions, such as multithreading, preemptive multi-process, long file name and UNC, users can execute multiple queries in the background, multiple database applications can access the same database file

The BDE architecture is based on the database driver, which provides a variety of shared services:

Buffers Management (buffer manager)

Sorting engine

OS Services

Memory management

BLOB Quick access

SQL query engine

SQL generator

Database refactoring

Batch processing of tables

Data Transformation Services

Connection Services

Memory Database Service

SQL Driver Services

System Management

Language management

Paradox, dbase, and text database BDE contain database drivers that support consistent access to standard data sources. Users can add ODBC-driven and Borland SQL links products to support data access to SQL Servers, such as InterBase Oracle and Sybase. In addition, BDE gives Windows 95 and Windows NT application developers direct, stand-alone, advanced access to a variety of data sources.