faq.html

来自「perl教程」· HTML 代码 · 共 1,069 行 · 第 1/4 页

If you do think you have managed to fix it, then, send a patch file
( context diff ) to the author with an explanation of:</p>
</dd>
<ul>
<li>
<p>What the problem was, and test cases, if possible.</p>
</li>
<li>
<p>What you needed to do to fix it. Please make sure you mention everything.</p>
</li>
<li>
<p>Platform information, database version, perl version, module version and 
DBI version.</p>
</li>
</ul>
<dt><strong><a name="item_email_the_author_do_not_whinge_21"><em>Email the author</em> Do <em>NOT</em> whinge!</a></strong>

<dd>
<p>Please email the address listed in the WWW pages for whichever driver you
are having problems with. Do <em>not</em> directly email the author at a
known address unless it corresponds with the one listed.</p>
</dd>
<dd>
<p>We tend to have real jobs to do, and we do read the mailing lists for
problems. Besides, we may not have access to &lt;<em>insert your
favourite brain-damaged platform here</em>&gt; and couldn't be of any
assistance anyway! Apologies for sounding harsh, but that's the way of it!</p>
</dd>
<dd>
<p>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 <em>do</em> appreciate the users'
problems, since we work in similar environments.</p>
</dd>
<dd>
<p>If you are planning to email the author, please furnish as much information
as possible, <em>ie</em>:</p>
</dd>
<ul>
<li>
<p><em>ALL</em> the information asked for in the README file in
the problematic module. And we mean <em>ALL</em> of it. We don't
put lines like that in documentation for the good of our health, or
to meet obscure README file standards of length.</p>
</li>
<li>
<p>If you have a core dump, try the <em>Devel::CoreStack</em> module for
generating a stack trace from the core dump. Send us that too.
<em>Devel::CoreStack</em> can be found on CPAN at:</p>
<pre>
    <a href="http://www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack">http://www.perl.com/cgi-bin/cpan_mod?module=Devel::CoreStack</a></pre>
</li>
<li>
<p>Module versions, perl version, test cases, operating system versions
and <em>any other pertinent information</em>.</p>
</li>
</ul>
<p>Remember, the more information you send us, the quicker we can track 
problems down. If you send us no useful information, expect nothing back.</p>
<p>Finally, please be aware that some authors, including Tim Bunce, specifically
request that you do <em>not</em> mail them directly. Please respect their wishes and
use the email addresses listed in the appropriate module <code>README</code> file.</p>
<dt><strong><a name="item_email_the_dbi_2dusers_mailing_list"><em>Email the dbi-users Mailing List</em></a></strong>

<dd>
<p>It's usually a fairly intelligent idea to <em>cc</em> the mailing list
anyway with problems. The authors all read the lists, so you lose nothing
by mailing there.</p>
</dd>
</li>
</dl>
<p>
</p>
<hr />
<h1><a name="platform_and_driver_issues">Platform and Driver Issues</a></h1>
<p>
</p>
<h2><a name="3_1_what_s_the_difference_between_odbc_and_dbi">3.1 What's the difference between ODBC and DBI?</a></h2>
<p>In terms of architecture - not much: Both define programming
interfaces. Both allow multiple drivers to be loaded to do the
actual work.</p>
<p>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.</p>
<p>Now there's an ODBC driver for the DBI (DBD::ODBC) the &quot;What's the
difference&quot; question is more usefully rephrased as:</p>
<p>Chapter 7 of &quot;Programming the Perl DBI&quot; covers this topic in far more
detail and should be consulted.</p>
<p>
</p>
<h2><a name="3_2_what_s_the_difference_between_win32__odbc_and_dbd__odbc">3.2 What's the difference between Win32::ODBC and DBD::ODBC?</a></h2>
<p>The DBI, and thus DBD::ODBC, has a different philosophy from the
Win32::ODBC module:</p>
<p>The Win32::ODBC module is a 'thin' layer over the low-level ODBC API.
The DBI defines a simpler 'higher level' interface.</p>
<p>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.)</p>
<p>The Win32::ODBC module only works on Win32 systems.
The DBI and DBD::ODBC are very portable and work on Win32 and Unix.</p>
<p>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).</p>
<p>Scripts written with the DBI and DBD::ODBC are faster than Win32::ODBC
on Win32 and are trivially portable to other supported database types.</p>
<pre>

The DBI offers optional automatic printing or die()ing on errors which
makes applications simpler and more robust.</pre>
<pre>

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.</pre>
<p>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.</p>
<p>Chapter 7 of &quot;Programming the Perl DBI&quot; covers this topic in far more
detail and should be consulted.</p>
<p>
</p>
<h2><a name="3_3_is_dbi_supported_under_windows_95___nt_platforms">3.3 Is DBI supported under Windows 95 / NT platforms?</a></h2>
<p>Finally, yes! Jeff Urlwin has been working diligently on building
<em>DBI</em> and <em>DBD::ODBC</em> under these platforms, and, with the
advent of a stabler perl and a port of <em>MakeMaker</em>, the project has
come on by great leaps and bounds.</p>
<p>The <em>DBI</em> and <em>DBD::Oracle</em> Win32 ports are now a standard part of DBI,
so, downloading <em>DBI</em> of version higher than <em>0.81</em> should work fine as 
should using the most recent <em>DBD::Oracle</em> version.</p>
<p>
</p>
<h2><a name="3_4_can_i_access_microsoft_access_or_sqlserver_databases_with_dbi">3.4 Can I access Microsoft Access or SQL-Server databases with DBI?</a></h2>
<p>Yes, use the <em>DBD::ODBC</em> driver.</p>
<p>
</p>
<h2><a name="3_5_is_the_a_dbd_for__insert_favourite_database_here_">3.5 Is the a DBD for &lt;<em>insert favourite database here</em>&gt;?</a></h2>
<p>Is is listed on the DBI drivers page?</p>
<pre>
    <a href="http://dbi.perl.org/">http://dbi.perl.org/</a>
    <a href="http://www.symbolstone.org/technology/perl/DBI">http://www.symbolstone.org/technology/perl/DBI</a></pre>
<p>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.</p>
<p>A corollary of the above statement implies that if you see an announcement
for a driver <em>not</em> on the above page, there's a good chance it's not
actually a <em>DBI</em> driver, and may not conform to the specifications. Therefore,
questions concerning problems with that code should <em>not</em> really be addressed
to the DBI Mailing Lists.</p>
<p>
</p>
<h2><a name="3_6_what_s_dbm_and_why_should_i_use_dbi_instead">3.6 What's DBM? And why should I use DBI instead?</a></h2>
<p>Extracted from ``<em>DBI - The Database Interface for Perl 5</em>'':</p>
<pre>
    ``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.</pre>
<pre>
        File Locking</pre>
<pre>
        The dbm systems did not allow particularly robust file locking
        capabilities, nor any capability for correcting problems arising through
        simultaneous writes [ to the database ].</pre>
<pre>
        Arbitrary Data Structures</pre>
<pre>
        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.</pre>
<pre>
    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.''</pre>
<p>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 <em>via</em> <em>DBI</em>.</p>
<p>Chapter 2 of &quot;Programming the Perl DBI&quot; discusses DBM files in detail.</p>
<p>
</p>
<h2><a name="3_7_what_database_do_you_recommend_me_using">3.7 What database do you recommend me using?</a></h2>
<p>This is a particularly thorny area in which an objective answer is difficult
to come by, since each dataset, proposed usage and system configuration
differs from person to person.</p>
<p>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 <em>mSQL</em> 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:</p>
<pre>
    <a href="http://www.hughes.com.au">http://www.hughes.com.au</a></pre>
<p>You may also wish to look at MySQL which is a more powerful database engine
that has a similar feel to mSQL.</p>
<pre>
    <a href="http://www.tcx.se">http://www.tcx.se</a></pre>
<p>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 <em>Oracle RDBMS</em>.
Oracle's WWW site is an excellent source of more information.</p>
<pre>
    <a href="http://www.oracle.com">http://www.oracle.com</a></pre>
<p><em>Informix</em> 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:</p>
<pre>
    <a href="http://www.informix.com">http://www.informix.com</a></pre>
<p>In the case of WWW fronted applications, <em>mSQL</em> 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. <em>mSQL</em>
is lighter resource-wise and faster.</p>
<p>These views are not necessarily representative of anyone else's opinions,
and do not reflect any corporate sponsorship or views. They are provided
<em>as-is</em>.</p>
<p>
</p>
<h2><a name="3_8_is__insert_feature_here__supported_in_dbi">3.8 Is &lt;<em>insert feature here</em>&gt; supported in DBI?</a></h2>
<p>Given that we're making the assumption that the feature you have requested
is a non-standard database-specific feature, then the answer will be <em>no</em>.</p>
<p>DBI reflects a <em>generic</em> API that will work for most databases, and has
no database-specific functionality.</p>
<p>However, driver authors may, if they so desire, include hooks to database-specific
functionality through the <code>func()</code> method defined in the DBI API.
Script developers should note that use of functionality provided <em>via</em>
the <code>func()</code> methods is very unlikely to be portable across databases.</p>
<p>
</p>
<hr />
<h1><a name="programming_questions">Programming Questions</a></h1>
<p>
</p>
<h2><a name="4_1_is_dbi_any_use_for_cgi_programming">4.1 Is DBI any use for CGI programming?</a></h2>
<p>In a word, yes! DBI is hugely useful for CGI programming! In fact, I would
tentatively say that CGI programming is one of two top uses for DBI.</p>
<p>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.</p>
<p>
</p>
<h2><a name="4_2_how_do_i_get_faster_connection_times_with_dbd__oracle_and_cgi">4.2 How do I get faster connection times with DBD::Oracle and CGI?</a></h2>
<pre>
    Contributed by John D. Groenveld</pre>
<p>The Apache <code>httpd</code> maintains a pool of <code>httpd</code> children to service client 
requests.</p>
<p>Using the Apache <em>mod_perl</em> module by <em>Doug MacEachern</em>, the perl 
interpreter is embedded with the <code>httpd</code> 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.</p>
<p>For more information on Apache, see the Apache Project's WWW site:</p>
<pre>
    <a href="http://www.apache.org">http://www.apache.org</a></pre>
<p>The <em>mod_perl</em> module can be downloaded from CPAN <em>via</em>:</p>
<pre>
    <a href="http://www.perl.com/cgi-bin/cpan_mod?module=Apache">http://www.perl.com/cgi-bin/cpan_mod?module=Apache</a></pre>
<p>
</p>
<h2><a name="4_3_how_do_i_get_persistent_connections_with_dbi_and_cgi">4.3 How do I get persistent connections with DBI and CGI?</a></h2>
<pre>
    Contributed by John D. Groenveld</pre>
<p>Using Edmund Mergl's <em>Apache::DBI</em> module, database logins are stored in a