Shulou(Shulou.com)05/31 Report--

This article introduces you how to understand MySQL's API interface, the content is very detailed, interested friends can refer to, hope to be helpful to you.

API interface of MySQL

To facilitate the development of applications, MySQL provides a client library written in the C programming language, which allows access to MySQL databases from within any C program. The client library implements the application programming interface (API), and API defines how the client program establishes and executes communication with the server.

However, there are no restrictions on using C to write MySQL programs. Many other language processors themselves are written in C or have the ability to use C libraries, so the MySQL client library provides this method, so that MySQL's constraints on these languages can be established on top of C API. This provides a number of options for writing applications to communicate with MySQL servers. The API of the client program is written in Perl, PHP, Java, Python, C++, Tcl, and other languages.

Each language constraint defines its own interface, especially the rules for accessing MySQL. There is not enough time to discuss every API that MySQL can use, let's just talk about the three most popular ones:

■ C client library API. This is the basic programming interface of MySQL.

DBI (database interface) API of the ■ Perl common target scripting language. DBI is implemented as a Perl module that interfaces with other modules at the DBD (database driver) level, and each module provides access to a specific type of database engine (of course, the specific DBD module we will discuss also provides support for MySQL). The most common use of DBI for MySQL is to write stand-alone clients called by the command line and scripts that try to be invoked by the Web server to provide Web access to MySQL.

■ PHP API . PHP is a scripting language that provides a convenient way to embed programs in Web pages. Before sending, such pages are processed by PHP, which allows these scripts to generate dynamic content, such as including the results of MySQL queries in the page. "PHP" originally means Personal Home Page, but PHP has grown far beyond its simple original functionality. The name now used by the PHP Web site stands for "PHP: hypertext preprocessor (Hypertext Preprocessor)", which references itself in the same way as GNU (GUN rather than UNIX).

When the standard MySQL client does not meet your needs, you do not always need to write your own program. Others have been writing programs, many of which are shareable. Just find a few and you can save a lot of work.

All three API types mentioned above are described in detail in a special chapter. This chapter only provides an overview of API comparisons to illustrate their basic characteristics and to give reasons for choosing one API over another for a particular application.

Of course, you don't have to think about just one API, you should know each API and use the API that suits you wisely. In large projects that include several components, multiple API and multiple languages may be used, depending on which language each subtask is appropriate for.

CAPI is used inside the context of compiling C programs. It is a client library that provides the lowest level of interface that can be used to talk to a MySQL server-- with the ability to create communication with the server. The Perl predecessor of DBI, the predecessor of DBI and PHP, is the Mysqlperl module Mysql.pm. This module is no longer supported and should not be used for the development of new MySQL. One thing to understand is that Mysqlperl is dependent on MySQL, but DBI is not. If you write Perl applications for MySQL and then decide that you want to use them with another database engine, it is easier to migrate DBI scripts than Mysqlperl scripts because they rarely rely on a specific database engine.

If you get a Perl script that accesses MySQL and find that it was written in Mysqlperl instead of DBI, you can still use DBI. DBI includes emulation support for Mysqlperl, so there is no need to install two packages. The predecessor of PHP3 is PHP/FI 2.0 (FI stands for "form interpreter, that is, format interpreter"). Like Mysqlperl, PHP/FI is obsolete, so we won't discuss it any further.

The origin of MySQLC API if you already have experience writing mSQL RDBMS programs, you will notice that MySQLC API is similar to the corresponding C API of mSQL. When MySQL developers began to implement their SQL engine, many useful shared utilities were available for mSQL. To minimize the difficulty of porting those mSQL utilities to MySQL utilities, MySQLAPI can be intentionally designed as a msql2mysql script similar to mSQL API (MySQL or even a simple textual alternative to the MySQL name corresponding to the mSQL API function name). This operation is relatively tedious and actually takes care of a lot of work that involves converting mSQL programs to use MySQL.

The C client provided by the MySQL distribution is based on this API. The C client library also provides services as the basis for MySQL's other language constraints, but Java API is an exception. For example, by connecting to the MySQLC client library code, MySQL can use the MySQL driver and PHP code specific to the Perl DBI module.

Perl DBI APIDBI API is used within the context of applications written in the Perl scripting language. This API is the highest of the three API structures we consider because it works with many databases while ignoring many specific database details in the script. DBI is implemented using a Perl module with a two-level structure.

■ DBI (database interface) level. Provides an interface for client scripts. This level provides an abstract interface, not a specific database engine.

■ DBD (database drive) level. At this level, support for various database engines is provided by engine-specific drivers.

MySQL's support environment for DBI is provided by the Msql-Mysql-modules distribution package. This module operates at the DBD level. It can be distinguished by the name of the distribution, and a driver can provide support for more than one RDBMS. Msql-Mysql-Modules was originally written for mSQL and later extended to MySQL. This effect is similar to CAPI for mSQL and MySQL. Since the design of MySQLCAPI is similar to mSQL CAPI, it makes sense to extend mSQL DBD (using mSQL CAPI) to the use of MySQL.

The style of writing applications in the DBI architecture is relatively common. When writing DBI scripts, you can use a standard set of calls. The DBI level invokes the appropriate driver at the DBD level to handle the request, and the driver handles the specific problems included in the specific database server communication you want to use. The DBD level transfers the data returned from the server and backs it up to the DBI level, making the data appear in the application. The format of the data is consistent with the data source of the database.

The result is an interface that hides the differences between database engines from the point of view of the application's writer, so that many different engines can be used-- as many as drivers. DBI increases portability by providing a consistent client interface by allowing each database to be accessed in a uniform style.

When you open a database, a database-specific interface written by a script appears. When creating a connection, you should indicate which driver to use.

Once connected, there is no need to make any special references to the driver. Let DBI and the driver work out the database-specific details.

In any case, it's a theoretical question. However, at least two factors contradict the portability of DBI scripts:

■ has different implementations of SQL between RDBMS engines, and it is entirely possible that SQL written for one engine does not understand the other engine at all. If SQL is fairly generic, scripts can be migrated between engines accordingly. But if SQL depends on the engine, the same is true of scripts. For example, if you use the SHOW TABLES statement specified by MySQL, the script cannot be executed with another database.

■ DBD modules typically provide engine-specific types of information to allow script writers to use specific features of a particular database system. For example, MySQLDBD provides methods to access column properties in query results, such as the maximum length of each column, whether the column is numeric, and so on. These attributes do not have any similarities in other databases. DBD's proprietary features are contrary to portability, and by using them, it is difficult to use scripts written by MySQL for other database systems.

Although these two factors exist for database-proprietary scripting, a DBI mechanism that provides database access in an abstract manner is a reasonable way to achieve portability, as long as you decide how many times to use it.

Like Perl, PHP is a scripting language. But unlike Perl, PHP is rarely designed as a common target language, but as a language for writing Web applications. PHP API is mainly used as a way to embed executable scripts in Web pages. This makes it easy for Web developers to write pages in a dynamic generation context.

When the client browser sends a request for a PHP page to the Web server, PHP executes any script it finds on the page and replaces it with the output of the script. The result is sent back to the browser. This makes the pages that actually appear in the browser vary depending on the requested page environment. For example, when you embed the following short PHP script in a Web page, it appears the host IP address of the requested page:

You can use scripts to provide visitors with up-to-date information based on the database context. The following example illustrates a simple script that can be used for a Historical League Web site. The script issues a request to determine the number of members of the current League and reports that number to those who visit the site (if there is an error, the script does not report any number):

Although the DBI level is database-independent and the DBD level is database-dependent, that is not what "DBI" and "DBD" represent. They mean "database interface" and "database driver".

A PHP script usually looks like a HTML page with a script embedded in the "" identifier. A page may include several scripts. This provides a very flexible approach to script development. For example, if you like, you can write a normal HTML page to create a generic page frame, and then add the content of the script.

For different database engines, PHP no longer does anything with a unified interface, and DBI also uses this approach. Instead, the interface for each engine looks very much like the corresponding C library interface that implements the engine's low-level API. For example, the name of the PHP function used to access MySQL from within the PHP script is very similar to the name of the function in the MySQL C client library.

This is the end of the API interface on how to understand MySQL. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.