Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

JDBC vs. ODBC: What's the difference between these APIs?

It's not unusual for database developers who move from Microsoft-based .NET platforms into the world of Java development to wonder, 'What's the difference between ODBC and JDBC?' It's a good question.

They have plenty in common, it's true, but the differences in the JDBC vs. ODBC API specifications require careful consideration.

Differences between ODBC and JDBC

There are significant differences between ODBC and JDBC. The first key difference in the JDBC vs. ODBC comparison is that JDBC is intimately associated with the Java language. ODBC is more egalitarian, and is accessible to programs written in a variety of languages, such as Visual Basic, .NET, C# and Fortran. JDBC only works within a Java Runtime Environment.

Another key difference between ODBC and JDBC is the set of compliant databases to a given standard. For example, Apache Derby is a relational database written entirely in Java; it supports only JDBC drivers. On the other hand, Microsoft Office supports only ODBC.

Similarities between ODBC and JDBC

There are many databases on the market, from enterprise systems -- such as IBM's DB2 and Microsoft's SQL Server -- to smaller options such as Apache Derby and Microsoft Access. They have their own capabilities and attributes, but they all share the same basic function: to store and provide access to relational data. The goal of both the JDBC and ODBC specification is to provide a single API comprised of a list of methods and functions that can be used with a compliant database.

JDBC vs. ODBC comparison chart

JDBC vs. ODBC comparison chart

At their cores, JDBC and ODBC are standardized APIs, which makes it possible to write code that will work with a variety of databases. Both APIs provide a consistent way to expose the functionality of an underlying RDBMS to software applications.

JDBC vs. ODBC and open standards

Many people associate ODBC with Microsoft because Microsoft integrates ODBC connectors right into its operating system. Furthermore, Microsoft has always promoted Microsoft Access as an ODBC-compliant database. In reality, the ODBC specification is based upon the Open Group's Call Level Interface specification, and is supported by a variety of vendors.

The JDBC specification is owned by Oracle and is part of the Java API. Evolution of the JDBC API, however, is driven by the open and collaborative JCP and Java Specification Requests. So while Oracle oversees the API development, progress is largely driven by the user community.

Despite the separate development paths of ODBC and JDBC, both allow support of various, agreed-upon specifications by RDBMS vendors. These standards are set by the International Standards Organization's data management and interchange committee, and both JDBC and ODBC vendors work to maintain compliance with the latest ISO specification. 

JDBC and ODBC drivers

JDBC and ODBC APIs work in similar ways. The specification outlines the various methods a developer can use to interact with the database. For those methods to work, the database vendor must provide a driver that takes the method call and converts it into a language the underlying database can understand. This allows any database differences to be handled by the driver developers, and not pushed back onto the software developers who wouldn't be as knowledgeable about the underlying RDBMS.

JDBC vs. ODBC vs. SQL

ODBC and JDBC APIs simplify interactions between software applications and RDBMS products. However, the basic language of relational databases is SQL. These database APIs respect that fact and allow SQL to be the main focus.

With JDBC and ODBC, queries, updates, inserts, joins and deletions are all accomplished with the issuing of SQL statements against the database. ODBC and JDBC provide facilities to make database connections easier, and they provide facilities to map the results of queries into language-specific data types such as string, integer and Boolean values. However, the key goal of these databases is to stay largely in the background, while structured query language does the bulk of the heavy lifting.

JDBC vs. ODBC performance

Much has been made about the performance results of JDBC and ODBC. But, when it comes to database interactions, the technology used to connect to the database is minimally significant in comparison to:

  • The actual queries made against the database;
  • How the database is configured;
  • What types of indexes exist on the database, and;
  • The granularity of queries being made against the database.

If the database is a performance bottleneck in your applications, the database is the place to look, not the ODBC or JDBC drivers themselves.

Both ODBC and JDBC drivers, however, are typically written in the C language or C#, so the drivers themselves are fast and efficient. Some JDBC drivers are written in Java, and the interpreted nature of the Java language may marginally reduce the speed at which commands are issued. Still, these speed differences are imperceptible in practice.

Again, if you have a database performance issue, the answer most likely resides at the database level, not in the connectivity technology used to interact with it.

The JDBC-ODBC driver bridge

It should be noted that it is possible to connect to an ODBC-compliant database with JDBC with a JDBC-ODBC driver. This driver takes JDBC calls, converts them into ODBC calls and then interacts with the target ODBC database. It's a great option when you need a bridge between the two systems, but it does come with its share of downsides.

One such drawback to this technique is the slow translation that's required between the two specifications. Another is that the feature set is limited. Not every feature of ODBC is exposed through the JDBC interface, and not every JDBC function is guaranteed to work as expected against the ODBC system. But, for basic operations and to issue standard SQL commands, the JDBC-ODBC driver will more than suffice.

View All Videos

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Have you seen a move away from relational database technologies and into NoSQL options like MongoDB and Cassandra?
Cancel
Until a revolutionary method for file system access, indexing, and writing is discovered, I'm afraid that the relational database will persist (da da, CHING!).  The RDBMS derives from the inherency of file system structure and access.  It is and will remain the fastest most optimized method of queried, transactional access to file system level information.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchHRSoftware

SearchSAP

SearchERP

Close