Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
Whether you're building a web- or desktop-based application with Java SE or Java EE, many Java applications need to integrate data from a relational database. This course describes how to read and manage data from relational databases such as MySQL and SQL Server using the Java Database Connectivity (JDBC) API.
Author David Gassner explains how to choose a JDBC driver and connect to one or more databases. He also provides detailed instructions on reading, selecting, and updating data; calling stored procedures; managing data via JavaBean classes or with prepared statements; and working with metadata.
Applications that use the JDBC API require drivers. A JDBC driver is a software library that encapsulates the logic you need to communicate between your application and a database management system or a database file stored on the local hard disk. All JDBC drivers follow the same set of rules that is the API, that's defined in Java Standard Edition. A driver library package will contain specific implementations of these Java interfaces.
Connection, which lets you connect to the database, ResultSet, which encapsulates data returned from the database, Statement, PreparedStatement, and CallableStatement, which represent requests to the database, and many more. Not all JDBC drivers will support all features of the JDBC spec. Check the documentation for your particular database and your particular driver to see what it's able to do. But nearly all JDBC drivers will support these five interfaces. Typically, you'll get your driver packages from the database vendors themselves, a MySQL driver from MySQL an Oracle driver for Oracle, and so on, but there are also third-party drivers available both free and commercial.
There are four distinct types of drivers, distinguished by their architecture. The oldest type of driver is called the Type 1 driver or the JDBC-ODBC Bridge. In the mid to late '90s when JDBC got started, ODBC or the Open Database Connectivity protocol was the dominant model for communicating with the database. And so Java first communicated with databases through ODBC. You would use the JDBC-ODBC Bridge driver, and then you would also use a separate ODBC driver that was designed for your specific database.
At runtime, requests would go from the application through the JDBC API to the Bridge driver from there to the ODBC driver and then to the database. This wasn't particularly fast, but it was dependable, and one of the pros was that you could talk to any database for which an ODBC driver existed, and that meant pretty much every relational database. The downsides of the ODBC Bridge driver are that it's not 100% Java and therefore not portable between operating systems. Also you're working with two drivers not just one, and they both have to be on the same computer as the application, so you have increased maintenance.
And finally, the ODBC driver has to match the database version, and so if you updated your database on the server, you'd have to go around to all the client applications and update those as well. The Type 2 driver combines a native API driver and a Java driver. They're both installed on the client system just like with the Bridge driver and the ODBC driver, but because you're working primarily with native APIs, the Type 2 driver tends to be very fast and can give you the best possible performance. Once again, just like the Bridge driver, you're not working in 100% Java, and therefore, your applications aren't portable between operating systems.
The native API driver has to be installed on the application client and maintained, and once again, if the database is updated, the client software has to be updated as well, but if you want the best possible performance, a Type 2 driver might be the way to go. The Type 3 driver actually is installed in multiple locations. You'll have 100% Java driver that's installed in the client along with the application, but then with the Type 3 driver architecture, you'll have a middleware server which hosts its own application, requests go at runtime from the application to the Type 3 driver that's installed on the client and from there over the network to the middleware server and from there to the database.
With a Type 3 driver, the middleware driver can be native, and so the communication between the middleware and the database can be very fast, but once again, you have maintenance challenges because you have more than one driver to maintain. The fourth type of driver, and one of the most common, is called the Type 4, or the 100% Java thin driver. With a 100% Java driver, there is only one driver package, not two, and the driver is packaged with the Java application itself, whether on a client computer, or in a web environment on a Java Enterprise Edition application server.
Requests go from your application to the driver that's on the client and then your communications go from the application through JDBC through the thin driver to the database server if it's out on the web, or to the database file if it's on the local hard disk. With the Java thin driver, you're communicating directly from the application to the database. There are no additional layers to install or maintain, and so maintenance is greatly simplified. The only downside is that you need a different driver package for each database you're working with.
Most applications will only use a single database type, but if you're working with more than one database management system, you'll need to provide multiple drivers. In this course I'll be doing all of my demonstrations with the two Type 4 drivers. One will be for the MySQL database server, and with this driver I'll show you how to communicate with a database server that's accessed over the web. I'll be actually working with a local copy of MySQL and addressing it as local host, but the code I'll be using would work just as well if the MySQL server were hosted out in the Cloud.
The other database I'll be working with in this course is called HyperSQL, or HSQLDB. HyperSQL is one of many pure Java databases that are used by Java developers, others include the Apache Derby database and H2. These databases run as in-memory databases. But the database is initialized with a local file, but then it runs in the same Java process as the application. So with these two drivers and these two database management systems, I'll be able to show you how to handle differences between databases while making your code as portable as possible, and I'll also be emphasizing the use of these Type 4 drivers, which are pure Java and can be encapsulated into your applications.
There are other types of drivers out there that aren't directly recognized by the JDBC API but can also be useful. For example, in 2010 there was talk of a Type 5 driver. A Type 5 driver has the same architecture as Type 4 that is it's 100% Java and Thin, but it gives you better performance than a pure Type 4 driver. And then there are other drivers that don't have specific type numbers that can run in the same Java process as the application just like the HyperSQL driver I'll show you. But if you stick with learning the four main types of drivers that are defined by JDBC, Types 1, 2, 3, and 4, those will cover the vast majority of JDBC drivers that are available to Java developers.
There are currently no FAQs about Java Database Integration with JDBC.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.