[Mpls-pm] Next meeting?

[jira0004]

Hi Chris,

I've never used Apache::DBI so I couldn't advise you
as to how well it works.

I've worked pretty extensively with the DBI module
itself.  My experience is that it works great.  It is
the best database programming interface that I have
worked with thus far.  The reason that I like it is
that it allows you to write SQL statements in strings,
and then execute those strings.  DBI works magically
when it comes to queries.  The developer writes the
SQL query statement as a string, binds variables to
the results of the query, executes the query and then
fetches the results into the given variables.  This
allows you to pull the results of the SQL query into
your Perl program.

The way that DBI works is you get or build a DBD
driver for your given type of database (Oracle,
PostgreSQL, MySQL, etc), howeverm you use the DBI
interface (not the DBD driver) to access your
database.  When you invoke a database handle via DBI
the specifications you use, cause DBI to use the
correct DBD driver (DBD::Pg for PostgreSQL for
example).

Since you only use the DBI interface directly and the
DBI interface selects the correct driver for your
database vendor (Oracle, PostgreSQL, MySQL, etc.) the
whole thing is independent of your specific database
vendor unless you use vendor-specific statements iin
your calls to the database.  DBI does usually support
most vendor-specific SQL statements.  For example,
PostgreSQL has a type called BLOB (Binary Large Object
similar to a CLOB in Oracle).  You can use DBI to work
with PostgreSQL BLOBs but then you couldn't use your
Perl database application on an Oracle database unless
you re-wrote the BLOB statements to handle Binary
Large Objects in an Oracle specific way.

Thus, you will be able to switch your application from
one database vendor to another without any
modifications if you avoid vendor specific stuff.

The one possible exception maybe date/time stamps. 
May experience with date/time data types in most
databases is that date/time data types are always
vendor specific.  Thus, you would probably have to
write one set of DBI statements for working with
date/time data for one database vendor (such as
Oracle) and write another different set of DBI
statements for working with date/time data for a
different vendor (such as PostgreSQL).

Let me know if you have any more questions and I will
give as clear of answers as I can.

Regards,

Peter Jirak
E: jira0004 at yahoo.com

--- Chris <cpj1 at visi.com> wrote:

> On Tue, 25 Oct 2005, jira0004 wrote:
> 
> > It really only makes sense for me to do a DBI talk
> or
> > a DBI "lightening" talk if there are developers in
> the
> > group that aren't familiar with DBI.  If most of
> the
> > developers in the group are reasonably familiar
> with
> > DBI, then it would be boring for them to listen to
> me
> > pontificate on DBI.
> 
> For what it's worth, I'm curious about two DBI
> aspects at this time.
> 
> 1. Apache::DBI.  Any thoughts on how well it works? 
> How does it handle
> with Apache2.  (I might actually have good answers
> on this myself in a
> month or so).
> 
> 2. Overall SQL compatability.  This is probably more
> on the SQL end
> compared to the perl end, but I'd like to make sure
> as much of my work
> done against a MySQL server will easily work on an
> Oracle server.
> 
> --------------------
> Christopher Josephes
> cpj1 at visi.com
>