Java JDBC编程深入指南

需积分: 22 153 浏览量更新于2024-07-27 收藏 1.6MB PDF 举报

"Java数据库编程，使用JDBC和Java 2nd Edition，是关于如何在Java环境中进行数据库编程的详细指南。" 在Java的世界里，数据库编程是一个至关重要的部分，尤其是对于企业级应用来说。Java Database Connectivity (JDBC) 是Oracle公司提供的一个API，它允许Java应用程序与各种关系型数据库进行交互。这本书"Database Programming With Jdbc And Java 2nd Edition"深入浅出地介绍了如何使用JDBC进行数据库操作。第1章：Java在企业中的角色，强调了Java作为企业开发工具的重要性。书中指出，数据库是支撑企业级应用的关键，而Java通过JDBC提供了强大的数据库编程能力。这一章还探讨了数据库的基本概念，以及如何利用Java来实现数据库编程。第2章：关系型数据库和SQL，首先解释了什么是关系型数据库，接着介绍了数据库引擎的概念，比如MySQL、Oracle和SQL Server等。然后，书本引导读者进入SQL的世界，教授基本的SQL语法，并提醒读者注意不同SQL版本之间的差异。第3章：JDBC入门，详细解释了JDBC是什么，它是如何工作的。这一章涵盖如何连接数据库，处理连接问题，执行基本的数据库访问操作，如增删改查。此外，还讨论了SQL数据类型与Java数据类型的对应，以及如何使用ScrollableResultSets增强查询能力。同时，通过介绍JDBCSupportClasses和一个简单的DatabaseServlet示例，使读者能更好地理解JDBC的实际应用。第4章：高级JDBC，扩展了JDBC的主题，包括使用预编译的SQL语句（PreparedStatement）以提高性能和安全性，选择合适的Statement类型，批量处理SQL语句，以及实现可更新的结果集。这一章还涉及了更复杂的数据类型处理和元数据的使用。第5章：JDBC可选包，这部分主要介绍了JDBC Optional Package，包括数据源（DataSource）的使用，这对于企业级应用中的连接管理至关重要。数据源可以实现连接池，有效地管理和复用数据库连接，以提高系统性能和稳定性。这本书提供了丰富的JDBC知识，不仅适合初学者理解JDBC的基础，也对有经验的开发者提供了关于如何优化和扩展JDBC应用的深入见解。无论是数据库连接、SQL语句的执行，还是高级特性的应用，都能在书中找到详尽的解释和实例。对于想要深入理解和使用Java进行数据库编程的读者，这是一本不可多得的参考书。

JDBC and Java 2

edition

age 13

transaction management. Building on this foundation, we will discuss JDBC and how it can be used

to execute SQL against any potential database engine.

1.3.1.1 SQL

The Java database API, JDBC, requires that the database being used support ANSI SQL2 as the

query language. The SQL language itself is worthy of a tiny mini-industry within the publishing

field, so covering it is well beyond the scope of this book.

[1]

The SQL in this book, however, stays

away from the more complex areas of the language and instead sticks with basic DELETE, INSERT,

SELECT, and UPDATE statements. For a short overview of SQL, check out Chapter 2.

[1]

O'Reilly is publishing a SQL reference guide, SQL in a Nutshell, by Kevin Kline with Daniel Kline.

The only additional level of complexity I use consists of stored procedures in the later chapters.

Stored procedures are precompiled SQL stored on the database server and executed by naming the

procedure and passing parameters to it. In other words, a stored procedure is much like a database

server function. Stored procedures provide an easy mechanism for separating Java programmers

from database issues and improving database performance.

1.3.1.2 JDBC

JDBC is in a SQL-level API that allows you to embed SQL statements as arguments to methods in

JDBC interfaces. To enable you to do this in a database-independent fashion, JDBC requires

database vendors (such as those mentioned earlier in this chapter) to furnish a runtime

implementation of its interfaces. These implementations route your SQL calls to the database in the

proprietary fashion it recognizes. As the programmer, though, you do not ever have to worry about

how it is routing SQL statements. The façade provided by JDBC gives you complete freedom from

any issues related to particular database issues; you can run the same code no matter what database

is present.

1.3.1.3 Transaction management

Transaction management involves packaging related database transactions into a single unit and

handling any error conditions that result. To get through this book, you need only to understand

basic transaction management in the form of beginning a transaction and either committing it on

success or aborting it on failure. JDBC provides you with the ability to auto-commit any transaction

on the atomic level (that is, statement by statement) or wait until a series of statements have

succeeded (or failed) and call the appropriate commit (or rollback) method.

1.3.2 Database Technologies

A Java application can use one of three major database architectures:

• Relational database

• Object database

• Object-relational database

The overwhelming majority of today's database applications use relational databases. The JDBC

API is thus heavily biased toward relational databases and their standard query language, SQL.

Relational databases find and provide relationships between data, so they collide head-on with

object solutions such as Java, since object-oriented philosophy dictates that an object's behavior is

inseparable from its data. In choosing the object-oriented reality of Java, you need to create a

JDBC and Java 2

edition

age 14

translation layer that maps the relational world into your object world. While JDBC provides you

with access to relational databases, it leaves the issue of object-to-relational mapping up to you.

Object databases, on the other hand, do not attempt to separate object data from behavior. The best

way to think of an object database is as a permanent store of objects with which your applications

can interface. This object-oriented encapsulation of data, however, makes it difficult to relate data

as well as relational databases do. Additionally, with JDBC so tightly bound to SQL, it is difficult

to create JDBC drivers to run against an object database. As of the writing of this book, Sun, in

cooperation with the Object Database Management Group (ODMG), is working on a specification

for a Java object database API.

Object-relational databases enjoy a "best of both worlds" advantage by providing both object and

relational means of accessing data. Until recently, object relational databases have relied almost

entirely on C++ objects to act as their object store. With all of the excitement around Java, however,

object-relational vendors are starting to enable their systems to support database objects written and

extended in Java. In this realm, your Java objects do not need to map relational data into business

objects. For the sake of easy, ad hoc querying, however, an object-relational database also provides

complex relational queries; sometimes these queries can even be done in an ANSI SQL superset

language.

1.4 Database Programming with Java

While the marriage of Java and database programming is beneficial to Java programmers, Java also

helps database programmers. Specifically, Java provides database programmers with the following

features they have traditionally lacked:

• Easy object to relational mapping

• Database independence

• Distributed computing

If you are interested in taking a pure object approach to systems development, you may have run

into the cold reality that most of the world runs on relational databases into which companies have

often placed hefty investments. This leaves you trying to map C++ and Smalltalk objects to

relational entities. Java provides an alternative to these two tools that frees you from the proprietary

interfaces associated with database programming. With the "write once, compile once, run

anywhere" power that JDBC offers you, Java's database connectivity allows you to worry about the

translation of relational data into objects instead of worrying about how you are getting that data.

A Java database application does not care what its database engine is. No matter how many times

the database engine changes, the application itself need never change. In addition, a company can

build a class library that maps its business objects to database entities in such a way that

applications do not even know whether or not their objects are being stored in a database. Later in

the book I discuss building a class library that allows you to map the data you retrieve through the

JDBC API into Java objects.

Java affects the way you distribute and maintain an application. A traditional client/server

application requires an administrator responsible for the deployment of the client program on users'

desktops. That administrator takes great pains to assure that each desktop provides a similar

operating environment so that the application may run as it was intended to run. When a change is

made to the application, the administrator makes the rounds and installs the upgrade.

JDBC and Java 2

edition

age 15

The Java language employs the idea of the zero-install client. The object code for the entire

application, client and server, resides on the network. Since the JVM provides an application with a

guaranteed runtime environment, no administration is needed for the configuration of that

environment for individual applications. The users simply use a virtual machine interface such as

HotJava to locate the desired application. By clicking on the application icon, a user can run it

without even realizing the application was never stored on their local machine.

The traditional application makes a clear distinction between the locations where processing occurs.

In traditional applications, database access occurs on the server, and GUI processing occurs on the

client; the objects on the client machine talk to the database through a specialized database API. In

other situations, the client might talk to the server through a set of TCP/IP or UDP/IP socket APIs.

Either way, a wall of complex protocols divides the objects found on the client from those on the

server. Java helps tear down this wall between client and server through another piece of its

Enterprise platform, RMI.

RMI allows applications to call methods in objects on remote machines as if those objects were

located on the same machine. Calling a method in another object in Java is of course as simple as

the syntax object.method(arg). If you want to call that method from a remote machine without

RMI, however, you would have to write code that allows you to send an object handle, a method

name, and arguments through a TCP/IP socket, translate it into an object.method(arg) call on the

remote end, perform the method call, pass the return value back across the socket, and then write a

bunch of code to handle network failures. That is a lot of work for a simple method call, and I did

not even get into the issues you would have to deal with, such as passing object references as

arguments and handling garbage collection on each end. Finally, since you have written this

complex protocol to handle method calls across the network, you have serious rewriting to do if you

decide that a given object needs to exist on the client instead of the server (or vice versa).

With RMI, any method call, whether on the same machine or across the network, uses the same

Java method call syntax. This freedom to distribute objects across the network is called a distributed

object architecture. Other languages use much more complex protocols like Common Object

Request Broker Architecture (CORBA) and the Distributed Computing Environment (DCE). RMI,

however, is a Java-specific API for enabling a distributed architecture. As such, it removes many of

the complexities of those two solutions.

For a client/server database application, a distributed architecture allows the various parts of the

application to refer to the same physical objects when referring to particular objects in the data

model. For example, take an airline ticketing system that allows customers on the Internet to book

flights. Current web applications would have a user download a bunch of flight information as an

HTML page. If I book the last seat on a flight that you are viewing at the same time, you will not

see my booking of that last seat. This is because on each client screen you simply see copies of data

from the database.

If you reconstruct this web application so that it uses RMI to retrieve data from a single flight object

on the server, you can allow any number of different customers to view the exact same plane

objects at the same time. In this way, you can be certain that all viewers see any change made to the

plane object simultaneously. When I book the last seat on that flight, the flight object makes an

RMI call to all clients viewing it to let them know another seat was booked.

1.4.1 Putting It All Together

The pieces of the story are now in place. You will be using JDBC for your database access and RMI

to distribute the objects that make up your application. This book covers the JDBC API in complete

JDBC and Java 2

edition

age 1

detail and discusses RMI as it pertains to the creation of distributed three-tier database applications.

To better use these APIs once you have gone beyond this book, I strongly recommend further

reading on these topics: object-oriented design methodologies, patterns in software development,

and general database programming.

Chapter 2. Relational Databases and SQL

Good sense is the most evenly shared thing in the world, for each of us thinks he is so well endowed

with it that even those who are the hardest to please in all other respects are not in the habit of

wanting more than they have. It is unlikely that everyone is mistaken in this. It indicates rather that

the capacity to judge correctly and to distinguish true from false, which is properly what one calls

common sense or reason, is naturally equal in all men, and consequently the diversity in our

opinions does not spring from some of us being more able to reason than others, but only from our

conducting our thoughts along different lines and not examining the same things.

— René Descartes, Discourse on the Method

Before you dive into the details of database programming in Java, I would like to take a chapter to

provide a basic discussion of relational databases for those of you who might have little or no

experience in this area. The subject of relational databases, however, is a huge topic that cannot

possibly be covered fully in this chapter. It is only designed to provide you with the most basic

introduction. Experienced database developers will find nothing new in this chapter; you will

probably want to skip ahead to Chapter 3.

2.1 What Is a Relational Database?

Programming is all about data processing; data is central to everything you do with a computer.

Databases—like filesystems—are nothing more than specialized tools for data storage. Filesystems

are good for storing and retrieving a single volume of information associated with a single virtual

location. In other words, when you want to save a WordPerfect document, a filesystem allows you

to associate it with a location in a directory tree for easy retrieval later.

Databases provide applications with a more powerful data storage and retrieval system based on

mathematical theories about data devised by Dr. E. F. Codd. Conceptually, a relational database can

be pictured as a set of spreadsheets in which rows from one spreadsheet can be related to rows from

another; in reality, however, the theory behind databases is much more complex. Each spreadsheet

in a database is called a table. As with a spreadsheet, a table is made up of rows and columns.

A simple way to illustrate the structure of a relational database is through a CD catalog. Let's say

that you have decided to create a database to keep track of your music collection. Not only do you

want to be able to store a list of your albums, but you also want to use this data later to help you

select music for parties. Your collection might look something like Table 2.1.

Table 2.1, A List of CDs from a Sample Music Collection

Artist Title Category Year

The Cure Pornography Alternative 1983

Garbage Garbage Alternative 1996

Hole Live Through This Alternative 1994

Nine Inch Nails The Downward Spiral Industrial 1994

Public Image Limited Compact Disc Alternative 1985

The Sex Pistols Never Mind the Bollocks, Here Come the Sex Pistols Punk 1977

JDBC and Java 2

edition

age 1

Skinny Puppy Last Rights Industrial 1992

Wire A Bell Is a Cup Until It Is Struck Alternative 1989

Of course, you could simply keep this list in a spreadsheet. But what if you wanted to have Johnny

Rotten night? Nothing in this list tells you which music in your catalog features him. You might

have another spreadsheet that lists musicians and the bands to which they belong, but there is

nothing about such a spreadsheet that can provide an easy programmatic answer to your question.

Databases and Database Engines

Developers new to database programming often run into problems understanding just

what a database is. In some contexts, it represents a collection of common data like the

music database you are looking at in this chapter. In other contexts, however, it may mean

the software used to support that collection of data, a process instance of that software, or

even the server machine on which the process is running.

Technically speaking, a database really is the collection of related data and the

relationships supporting the data. The database software is the software—such as Oracle,

Sybase, MySQL, and UDB—that is used to access that data. A database engine, in turn, is

a process instance of the software accessing your database. Finally, the database server is

the computer on which the database engine is running.

I will continue to use the term database interchangeably to refer to any of these

definitions. It is important, however, to database programming to understand this

breakdown.

With a database, you could easily ask the question "Can you give me all compact discs in my

collection with which Johnny Rotten was involved?" We will formally ask that question in a

minute. To make asking that question easier, however, you have to design your database to store the

information you need so that you can relate compact discs to individual musicians. You might

create another table called musicians that stores a list of musicians. For your purposes, you will

store only last names, first names, and nicknames in this list. However, you could store more

information, such as birthdays. Table 2.2

shows a part of your list.

Table 2.2, The Data in the Musicians Table

Last Name First Name Nickname

Jourgenson Al

Lydon John Johnny Rotten

Reznor Trent

Smith Robert

Nothing in these two lists relates musicians to bands, much less musicians to compact discs.

Another problem you can see in this list is that Robert Smith is a very common name, and there are

likely multiple artists who have that name. How do you know which Robert Smith should be related

to which compact disc? Database tables generally have one or more columns called keys that

uniquely identify each row. The key of the albums table could be the CD title; it is not uncommon,

however, for the same title to be used for different albums by different bands. The simplest thing to

do is to add another column to serve as the key column—let's call it an album ID. This column will

just be a sequential list of numbers. As you add new discs to the collection, increment the album ID

by one and insert that information. Thus album 1 is The Cure's Pornography, album 2 is Garbage's

剩余252页未读，继续阅读

markinlqx

粉丝: 4
资源: 4

Java JDBC编程深入指南

java-spring-base:JavaSpring Base项目供其他项目使用

Java专业术语 英语词汇.doc

Athena Framework for Java 2.0

java去掉base64中的data:image/jpeg;base64

使用java实现Base64.stringify

java解析base64

java去掉data:image/jpeg;base64

java中data:image/svg+xml;base64,转data:image/png;base64,

java使用base64

java 实现base64图片转BufferedImage

最新资源

Java专业术语英语词汇.doc