ODBC, JDBC, and four types of drives _ODBC

There is no common application programming interface in early database development areas, and developers must learn and use vendor-specific APIs when using different database products, such as Oracle call Interface, Microsoft Database library, and so on. In response to the industry's demand for universal programming interfaces, Microsoft has launched an ODBC (Open Database connectivity) program that is recognized by vendors and developers. ODBC establishes a set of specifications and provides a standard API for database access, which was later adopted by X/open and ISO/IEC as part of the SQL standard.

Sun referenced ODBC and designed a dedicated database connection specification JDBC (Java Database Connectivity) for Java. The goal of JDBC is to allow Java developers to have a unified interface when writing database applications, without relying on specific database APIs to achieve "one development, all databases." Although it is often impossible to achieve goals because of the use of database-specific syntax, data types, or functions, JDBC standards greatly simplify development efforts.

The JDBC standard is divided into two parts: the application development interface for application developers and the developer (usually database vendor) interface for database drivers. In the JDBC standard, the driver is divided into four types by operation.

Type 1:jdbc-odbc Bridge Driver

When Sun publishes the JDBC specification, there are not many JDBC drivers available on the market, but the maturing ODBC scheme makes it possible to connect almost all types of data sources through an ODBC driver. So Sun has released the Jdbc-odbc Bridge Drive, using off-the-shelf ODBC architectures to convert JDBC calls to ODBC calls, avoiding the embarrassment of JDBC's drive-free availability.

However, due to bridge constraints, not all features can be directly converted and normal calls, and multi-layer call conversion has a certain impact on speed, unless there is no other solution, the bridging schema should not be used.

Type 2:native API Driver

This type of driver directly invokes the native link library or client provided by the database, because there is no intermediate process and the access speed is usually good. However, the driver is bound to the database and platform and cannot achieve the basic purpose of JDBC Cross-platform. In the JDBC specification It is also an option that is not recommended.

Type 3:jdbc-net Driver

This type of driver converts a JDBC call to a database-independent protocol, which is then converted to a database communication protocol through a specific intermediate component or server, with the main purpose of obtaining better architectural flexibility. For example, replacing a database can be achieved by replacing the intermediate component. Type 3 drives developed by non-database vendors often provide additional functionality, such as advanced security features, but can also have a certain impact on speed through intermediate server conversions. This type of driver is not common in the JDBC domain, and Microsoft's ado.net is typical of this architecture.

Type 4:native Protocol Driver

This is the most common driver type, and the driver jar packages used in our development are basically in this category, and are typically provided directly by the database vendor, such as Mysql-connector-java, where the driver converts JDBC calls into database-specific network communication protocols. Because of the use of network communications, the driver can be a pure Java implementation, support Cross-platform deployment, performance is also better.