Chapter 7. ODBC and the DBI
Open Database Connectivity, commonly known as
ODBC
, defines a
database-independent API. The
ODBC Driver Manager
supports the API and manages one
or more plug-in drivers for talking to different types of databases.
The architecture is shown in Figure 7-1.
Figure 7-1. The ODBC architecture
Doesn't this all sound rather familiar? The ODBC driver manager
and drivers are doing just what the DBI and its drivers are doing:
defining and implementing a database-independent,
application-programming interface.
This leads us to a whole bunch of questions: What's the
difference? Why not just use ODBC and not the DBI? Can the DBI and
ODBC work together? What advantages does one have over the other?
Before we try to answer those questions, let's get some
perspective by looking into the history and goals of ODBC and the
DBI, and take a look at the Win32::ODBC module,
which implements a direct interface to ODBC for Perl.
7.1. ODBC -- Embraced and Extended
In the early 1990s, a consortium of vendors formed the
SQL Access
Group to support SQL interoperability across disparate systems. In
October 1992 and October 1993, a major part of that work was
published as a draft standard entitled
"Call Level Interface," or CLI,
which is another name for an Application Programing
Interface, or API. However, the SQL Access Group CLI standard never
really took off. At least, not in that form.
Microsoft needed to implement a similar concept, to avoid having to
release multiple versions of any product that needed to talk to
multiple databases. They saw the SQL Access Group CLI standard and
``embraced and extended'' it, radically. The
result was the Open Database Connectivity interface, which rapidly
became a de facto standard. In fairness, Microsoft turned an
incomplete paper standard into a fully featured practical reality.
 |  |  | | 6.3. Transactions, Locking, and Isolation |  | 7.2. DBI -- Thrashed and Mutated |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
|
