Партнёры:
Хостинг:
DBI::FAQ -- The Frequently Asked Questions for the Perl5 Database Interface
perldoc DBI::FAQ
``DBI is a database access Application Programming Interface (API)
for the Perl Language. The DBI API Specification defines a set
of functions, variables and conventions that provide a consistent
database interface independant of the actual database being used.''
In simple language, the DBI interface allows users to access multiple database types transparently. So, if you connecting to an Oracle, Informix, mSQL, Sybase or whatever database, you don't need to know the underlying mechanics of the 3GL layer. The API defined by DBI will work on all these database types.
A similar benefit is gained by the ability to connect to two different databases of different vendor within the one perl script, ie, I want to read data from an Oracle database and insert it back into an Informix database all within one program. The DBI layer allows you to do this simply and powerfully.
DBperl is the old name for the interface specification. It's usually now used to denote perl4 modules on database interfacing, such as, oraperl, isqlperl, ingperl and so on. These interfaces didn't have a standard API and are generally not supported.
Here's a list of DBperl modules, their corresponding DBI counterparts and support information. Please note, the author's listed here generally do not maintain the DBI module for the same database. These email addresses are unverified and should only be used for queries concerning the perl4 modules listed below. DBI driver queries should be directed to the dbi-users mailing list.
Module Name Database Required Author DBI
----------- ----------------- ------ ---
Sybperl Sybase Michael Peppler DBD::Sybase
<mpeppler@itf.ch>
Oraperl Oracle 6 & 7 Kevin Stock DBD::Oracle
<dbi-users@perl.org>
Ingperl Ingres Tim Bunce & DBD::Ingres
Ted Lemon
<dbi-users@perl.org>
Interperl Interbase Buzz Moschetti DBD::Interbase
<buzz@bear.com>
Uniperl Unify 5.0 Rick Wargo None
<rickers@coe.drexel.edu>
Pgperl Postgres Igor Metz DBD::Pg
<metz@iam.unibe.ch>
Btreeperl NDBM John Conover SDBM?
<john@johncon.com>
Ctreeperl C-Tree John Conover None
<john@johncon.com>
Cisamperl Informix C-ISAM Mathias Koerber None
<mathias@unicorn.swi.com.sg>
Duaperl X.500 Directory Eric Douglas None
User Agent
However, some DBI modules have DBperl emulation layers, so, DBD::Oracle comes with an Oraperl emulation layer, which allows you to run legacy oraperl scripts without modification. The emulation layer translates the oraperl API calls into DBI calls and executes them through the DBI switch.
Here's a table of emulation layer information:
Module Emulation Layer Status
------ --------------- ------
DBD::Oracle Oraperl Complete
DBD::Informix Isqlperl Under development
DBD::Ingres Ingperl Complete?
DBD::Sybase Sybperl Working? ( Needs verification )
DBD::mSQL Msqlperl Experimentally released with
DBD::mSQL-0.61
The Msqlperl emulation is a special case. Msqlperl is a perl5 driver for mSQL databases, but does not conform to the DBI Specification. It's use is being deprecated in favour of DBD::mSQL. Msqlperl may be downloaded from CPAN via:
http://www.perl.com/cgi-bin/cpan_mod?module=Msqlperl
http://www.perl.com/CPAN/
For more specific version information and exact URLs of drivers, please see the DBI drivers list and the DBI module pages which can be found on:
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
This list is automatically generated on a nightly basis from CPAN and should be up-to-date.
The table of contents is:
Preface
1. Introduction
From Mainframes to Workstations
Perl
DBI in the Real World
A Historical Interlude and Standing Stones
2. Basic Non-DBI Databases
Storage Managers and Layers
Query Languages and Data Functions
Standing Stones and the Sample Database
Flat-File Databases
Putting Complex Data into Flat Files
Concurrent Database Access and Locking
DBM Files and the Berkeley Database Manager
The MLDBM Module
Summary
3. SQL and Relational Databases
The Relational Database Methodology
Datatypes and NULL Values
Querying Data
Modifying Data Within Tables
Creating and Destroying Tables
4. Programming with the DBI
DBI Architecture
Handles
Data Source Names
Connection and Disconnection
Error Handling
Utility Methods and Functions
5. Interacting with the Database
Issuing Simple Queries
Executing Non-SELECT Statements
Binding Parameters to Statements
Binding Output Columns
do() Versus prepare()
Atomic and Batch Fetching
6. Advanced DBI
Handle Attributes and Metadata
Handling LONG/LOB Data
Transactions, Locking, and Isolation
7. ODBC and the DBI
ODBC -- Embraced and Extended
DBI -- Thrashed and Mutated
The Nuts and Bolts of ODBC
ODBC from Perl
The Marriage of DBI and ODBC
Questions and Choices
Moving Between Win32::ODBC and the DBI
And What About ADO?
8. DBI Shell and Database Proxying
dbish -- The DBI Shell
Database Proxying
A. DBI Specification
B. Driver and Database Characteristics
C. ASLaN Sacred Site Charter
Index
The book should be available from all good bookshops and can be ordered online either <I>via</I> O'Reilly & Associates
http://www.oreilly.com/catalog/perldbi
or Amazon
http://www.amazon.com/exec/obidos/ASIN/1565926994/dbi
perldoc DBI
command. The Specification also forms Appendix A of ``Programming the Perl DBI''.
perldoc Oraperl
This will produce an updated copy of the original oraperl man page written by Kevin Stock for perl4. The oraperl API is fully listed and described there.
perldoc <driver>
For example, the DBD::mSQL driver is bundled with driver-specific documentation that can be accessed by typing
perldoc DBD::mSQL
perldoc DBI::FAQ
This may be more convenient to persons not permanently, or conveniently, connected to the Internet. The DBI::FAQ module should be downloaded and installed for the more up-to-date version.
The version of DBI::FAQ shipped with the "DBI" module may be slightly out of date.
perldoc perlpod
Users with the Tk module installed may be interested to learn there is a Tk-based POD reader available called "tkpod", which formats POD in a convenient and readable way. This is available via CPAN as the module called Tk::POD and is highly recommended.
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
in the driver information table. These summaries contain standardised information on each driver and database which should aid you in selecting a database to use. It will also inform you quickly of any issues within drivers or whether a driver is not fully compliant with the DBI Specification.
http://dbi.perl.org/tidbits
http://www.symbolstone.org/technology/perl/DBI/tidbits
There are a series of occasional rambles from various people on the DBI mailing lists who, in an attempt to clear up a simple point, end up drafting fairly comprehensive documents. These are quite often varying in quality, but do provide some insights into the workings of the interfaces.
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
These articles are of varying quality and age, from the original Perl Journal article written by Alligator and Tim, to more recent debacles published online from about.com.
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
dbi-announce@perl.org -- for announcements, very low traffic
dbi-users@perl.org -- general user support
dbi-dev@perl.org -- for driver developers (no user support)
For information on how to subscribe, set digest mode etc, and unsubscribe, send an email message (the content will be ignored) to:
dbi-announce-help@perl.org
dbi-users-help@perl.org
dbi-dev-help@perl.org
http://outside.organic.com/mail-archives/dbi-users/
Searchable hypermail archives of the three mailing lists, and some of the much older traffic have been set up for users to browse.
http://www.rosat.mpe-garching.mpg.de/mailing-lists/PerlDB-Interest
As per the US archive above.
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
If it's a known problem, you'll probably have to wait till it gets fixed. If you're really needing it fixed, try the following:
We tend to have real jobs to do, and we do read the mailing lists for problems. Besides, we may not have access to <insert your favourite brain-damaged platform here> and couldn't be of any assistance anyway! Apologies for sounding harsh, but that's the way of it!
However, you might catch one of these creative genii at 3am when we're doing this sort of stuff anyway, and get a patch within 5 minutes. The atmosphere in the DBI circle is that we do appreciate the users' problems, since we work in similar environments.
If you are planning to email the author, please furnish as much information as possible, ie:
http://www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack
Remember, the more information you send us, the quicker we can track problems down. If you send us no useful information, expect nothing back.
Finally, please be aware that some authors, including Tim Bunce, specifically request that you do not mail them directly. Please respect their wishes and use the email addresses listed in the appropriate module "README" file.
In terms of ease of use - much: The DBI is a 'high level' interface that, like Perl itself, strives to make the simple things easy while still making the hard things possible. The ODBC is a 'low level' interface. All nuts-bolts-knobs-and-dials.
Now there's an ODBC driver for the DBI (DBD::ODBC) the ``What's the difference'' question is more usefully rephrased as:
Chapter 7 of ``Programming the Perl DBI'' covers this topic in far more detail and should be consulted.
The Win32::ODBC module is a 'thin' layer over the low-level ODBC API. The DBI defines a simpler 'higher level' interface.
The Win32::ODBC module gives you access to more of the ODBC API. The DBI and DBD::ODBC give you access to only the essentials. (But, unlike Win32::ODBC, the DBI and DBD::ODBC do support parameter binding and multiple prepared statements which reduces the load on the database server and can dramatically increase performance.)
The Win32::ODBC module only works on Win32 systems. The DBI and DBD::ODBC are very portable and work on Win32 and Unix.
The DBI and DBD::ODBC modules are supplied as a standard part of the Perl 5.004 binary distribution for Win32 (they don't work with the older, non-standard, ActiveState port).
Scripts written with the DBI and DBD::ODBC are faster than Win32::ODBC on Win32 and are trivially portable to other supported database types.
The DBI offers optional automatic printing or die()ing on errors which makes applications simpler and more robust.
The current DBD::ODBC driver version 0.16 is new and not yet fully stable. A new release is due soon [relative to the date of the next TPJ issue :-] and will be much improved and offer more ODBC functionality.
To summarise: The Win32::ODBC module is your best choice if you need access to more of the ODBC API than the DBI gives you. Otherwise, the DBI and DBD::ODBC combination may be your best bet.
Chapter 7 of ``Programming the Perl DBI'' covers this topic in far more detail and should be consulted.
The DBI and DBD::Oracle Win32 ports are now a standard part of DBI, so, downloading DBI of version higher than 0.81 should work fine as should using the most recent DBD::Oracle version.
http://dbi.perl.org/
http://www.symbolstone.org/technology/perl/DBI
If not, no. A complete absence of a given database driver from that page means that no-one has announced any intention to work on it, not that such a driver is impossible to write.
A corollary of the above statement implies that if you see an announcement for a driver not on the above page, there's a good chance it's not actually a DBI driver, and may not conform to the specifications. Therefore, questions concerning problems with that code should not really be addressed to the DBI Mailing Lists.
``UNIX was originally blessed with simple file-based ``databases'', namely
the dbm system. dbm lets you store data in files, and retrieve
that data quickly. However, it also has serious drawbacks.
File Locking
The dbm systems did not allow particularly robust file locking
capabilities, nor any capability for correcting problems arising through
simultaneous writes [ to the database ].
Arbitrary Data Structures
The dbm systems only allows a single fixed data structure:
key-value pairs. That value could be a complex object, such as a
[ C ] struct, but the key had to be unique. This was a large
limitation on the usefulness of dbm systems.
However, dbm systems still provide a useful function for users with
simple datasets and limited resources, since they are fast, robust and
extremely well-tested. Perl modules to access dbm systems have now
been integrated into the core Perl distribution via the
AnyDBM_File module.''
To sum up, DBM is a perfectly satisfactory solution for essentially read-only databases, or small and simple datasets. However, for more scaleable dataset handling, not to mention robust transactional locking, users are recommended to use a more powerful database engine via DBI.
Chapter 2 of ``Programming the Perl DBI'' discusses DBM files in detail.
From the current author's point of view, if the dataset is relatively small, being tables of less than 1 million rows, and less than 1000 tables in a given database, then mSQL is a perfectly acceptable solution to your problem. This database is extremely cheap, is wonderfully robust and has excellent support. More information is available on the Hughes Technology WWW site at:
http://www.hughes.com.au
You may also wish to look at MySQL which is a more powerful database engine that has a similar feel to mSQL.
http://www.tcx.se
If the dataset is larger than 1 million row tables or 1000 tables, or if you have either more money, or larger machines, I would recommend Oracle RDBMS. Oracle's WWW site is an excellent source of more information.
http://www.oracle.com
Informix is another high-end RDBMS that is worth considering. There are several differences between Oracle and Informix which are too complex for this document to detail. Information on Informix can be found on their WWW site at:
http://www.informix.com
In the case of WWW fronted applications, mSQL may be a better option due to slow connection times between a CGI script and the Oracle RDBMS and also the amount of resource each Oracle connection will consume. mSQL is lighter resource-wise and faster.
These views are not necessarily representative of anyone else's opinions, and do not reflect any corporate sponsorship or views. They are provided as-is.
DBI reflects a generic API that will work for most databases, and has no database-specific functionality.
However, driver authors may, if they so desire, include hooks to database-specific functionality through the "func()" method defined in the DBI API. Script developers should note that use of functionality provided via the "func()" methods is very unlikely to be portable across databases.
DBI confers the ability to CGI programmers to power WWW-fronted databases to their users, which provides users with vast quantities of ordered data to play with. DBI also provides the possibility that, if a site is receiving far too much traffic than their database server can cope with, they can upgrade the database server behind the scenes with no alterations to the CGI scripts.
Contributed by John D. Groenveld
The Apache "httpd" maintains a pool of "httpd" children to service client requests.
Using the Apache mod_perl module by Doug MacEachern, the perl interpreter is embedded with the "httpd" children. The CGI, DBI, and your other favorite modules can be loaded at the startup of each child. These modules will not be reloaded unless changed on disk.
For more information on Apache, see the Apache Project's WWW site:
http://www.apache.org
The mod_perl module can be downloaded from CPAN via:
http://www.perl.com/cgi-bin/cpan_mod?module=Apache
Contributed by John D. Groenveld
Using Edmund Mergl's Apache::DBI module, database logins are stored in a hash with each of these "httpd" child. If your application is based on a single database user, this connection can be started with each child. Currently, database connections cannot be shared between "httpd" children.
Apache::DBI can be downloaded from CPAN via:
http://www.perl.com/cgi-bin/cpan_mod?module=Apache::DBI
The "httpd" process usually runs under the user id of "nobody", which implies there is no configured environment. Any scripts attempting to execute in this situation will correctly fail.
One way to solve this problem is to set the environment for your database in a "BEGIN { }" block at the top of your script. Another technique is to configure your WWW server to pass-through certain environment variables to your CGI scripts.
Similarly, you should check your "httpd" error logfile for any clues, as well as the ``Idiot's Guide To Solving Perl / CGI Problems'' and ``Perl CGI Programming FAQ'' for further information. It is unlikely the problem is DBI-related.
The ``Idiot's Guide To Solving Perl / CGI Problems'' can be located at:
http://www.perl.com/perl/faq/index.html
as can the ``Perl CGI Programming FAQ''. Read BOTH these documents carefully!
It is expected that some future version of the DBI will at least be thread-safe (but not thread-hot) by automatically blocking threads intering the DBI while it's already in use.
For some OCI example code for Oracle that has multi-threaded "SELECT" statements, see:
http://www.symbolstone.org/technology/oracle/oci/orathreads.tar.gz
For example:
### $dbh is a connected database handle
$sth = $dbh->prepare( "SELECT blob_column FROM blobby_table" );
$sth->execute;
would fail.
### $dbh is a connected database handle
### Set the maximum BLOB size...
$dbh->{LongReadLen} = 16384; ### 16Kb...Not much of a BLOB!
$sth = $dbh->prepare( "..." );
would succeed <I>provided no column values were larger than the specified value</I>.
If the BLOB data is longer than the value of "LongReadLen", then an error will occur. However, the DBI provides an additional piece of functionality that will automatically truncate the fetched BLOB to the size of "LongReadLen" if it is longer. This does not cause an error to occur, but may make your fetched BLOB data useless.
This behaviour is regulated by the "LongTruncOk" attribute which is defaultly set to a false value ( thus making overlong BLOB fetches fail ).
### Set BLOB handling such that it's 16Kb and can be truncated
$dbh->{LongReadLen} = 16384;
$dbh->{LongTruncOk} = 1;
Truncation of BLOB data may not be a big deal in cases where the BLOB contains run-length encoded data, but data containing checksums at the end, for example, a ZIP file, would be rendered useless.
However, most database that support them also provide a way to call them from SQL statements - and the DBI certainly supports that.
So, assuming that you have created a stored procedure within the target database, eg, an Oracle database, you can use $dbh->"do()" to immediately execute the procedure. For example,
$dbh->do( "BEGIN someProcedure; END;" ); # Oracle-specific
You should also be able to "prepare" and "execute", which is the recommended way if you'll be calling the procedure often.
Contributed by Jeff Urlwin
$sth = $dbh->prepare( "BEGIN foo(:1, :2, :3); END;" );
$sth->bind_param(1, $a);
$sth->bind_param_inout(2, \$path, 2000);
$sth->bind_param_inout(3, \$success, 2000);
$sth->execute;
Remember to perform error checking, though! ( Or use the "RaiseError" attribute ).
Some drivers, therefore, support database creation and deletion through the private "func()" methods. You should check the documentation for the drivers you are using to see if they support this mechanism.
Chapter 6 of ``Programming the Perl DBI'' discusses transaction handling within the context of DBI in more detail.
$rv = $dbh->do( "INSERT INTO table VALUES( NULL )" );
but when queried back, the "NULL"s should be tested against "undef". This is standard across all drivers.
$rv =$dbh->func( 'argument', 'createDatabase' );
Software developers should note that the "func()" methods are non-portable between databases.
You may also wish to read the ``Does Perl have a Year 2000 problem?'' section of the Perl FAQ at:
http://www.perl.com/CPAN/doc/FAQs/FAQ/PerlFAQ.html
However, some organizations are providing either technical support or training programs on DBI. The present author has no knowledge as to the quality of these services. The links are included for reference purposes only and should not be regarded as recommendations in any way. Caveat emptor.
http://www.perlclinic.com
See:
http://www.westlake.com/training
for more details.
http://www-ccs.cs.umass.edu/db.html
http://www.odmg.org/odmg93/updates_dbarry.html
http://www.jcc.com/sql_stnd.html
This document is Copyright (c)1997-2000 Alligator Descartes. All rights reserved. Permission to distribute this document, in full or in part, via email, Usenet, ftp archives or http is granted providing that no charges are involved, reasonable attempt is made to use the most current version and all credits and copyright notices are retained ( the AUTHOR and COPYRIGHT sections ). Requests for other distribution rights, including incorporation into commercial products, such as books, magazine articles or CD-ROMs should be made to Alligator Descartes <http://www.symbolstone.org/descarte/contact.html>.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |