A JDBC URL provides a way of locating a data source so that the appropriate
driver will recognize it and establish a connection with it. Developers of
drivers are the ones who determine which JDBC URL identifies a particular
driver. Users do not need to worry about how to form a JDBC URL; they simply
use the URL that is supplied with the drivers they are using.
The role of JDBC is to recommend some conventions for driver developers
to follow in structuring their JDBC URLs. Since various kinds of drivers use
JDBC URLs, these conventions are by necessity very flexible.
- They allow different drivers to use different schemes for naming databases.
For example, the ODBC sub-protocol lets the URL contain attribute values (but
does not require them).
- They allow driver developers to encode all necessary connection information
within them. This makes it possible, for example, for an applet to talk to
a given database by opening the database connection without requiring the
user to do any system administration chores.
- They allow a level of abstraction. This means that the JDBC URL may refer
to a logical host or database name that is dynamically translated to the actual
name by a network naming service. This allows system administrators to avoid
specifying particular hosts as part of the JDBC name. There are a number of
different network name services (such as DNS, NIS, and DCE) and there is no
restriction as to which one can be used.
The standard syntax for a JDBC URL has the following three parts, separated
by colons:
jdbc:<subprotocol>:<subname>
The three parts of a JDBC URL are broken down as follows:
- jdbc, the protocol identifier. The protocol in a JDBC URL is always jdbc.
- <subprotocol>, the name of the driver or the name
of a database connectivity mechanism, which may be supported by one or more
drivers. A prominent example of a subprotocol name is odbc, which has been
reserved for URLs that specify ODBC-style data source names. For example,
to access a database through a JDBC-ODBC bridge, you might use a URL such
as the following:
jdbc:odbc:fred
In this example, the subprotocol is odbc, and the subname fred
is a local ODBC data source. If you want to use a network naming service
(so that the database name in the JDBC URL does not have to be its actual
name), the naming service can be the subprotocol. For example, a URL could
be:
jdbc:dcenaming:accounts-payable
In this example, the URL specifies that the local DCE naming service
should resolve the database name accounts-payable into a more specific name
that can be used to connect to the real database
- <subname>, a way to identify the data source. The
subname can vary, depending on the subprotocol, and it can have any internal
syntax the driver writer chooses, including a subsubname. The purpose of a
subname is to give enough information to locate the data source. In the previous
example, fred is assumed to be enough because ODBC is assumed to provide the
remainder of the information. A data source on a remote server requires more
information, for example, if the data source is accessed over the Internet,
the Internet address should be included in the JDBC URL as part of the subname
and should adhere to the following standard URL naming convention:
//hostname:port/subsubname
Supposing that dbnet is a protocol for connecting to a host on
the Internet, the following might be a JDBC URL:jdbc:dbnet://wombat:356/fred