Look at Michael Schwern's Class::DBI on CPAN.

On 28-Jul-2000 Michael Nachbaur wrote:
>  <Warn priority="low">
>    <warning class="Off Topic"/>
>    <warning class="Long"/>
>  </Warn>
>  
>  I'm not exactly sure where to send this, but here it goes:
>  Has anyone completed/started an abstract database class at all?  I've written
>  some for very specific applications, but I want a more general-purpose tool. 
>  I'm about to start development on one, but wanted to get feedback from the
>  world-at-large to see what features you would want first (or if anyone has
>  already started one).
>  
>  The classes I've created/used before, are like:
>  my $order = new Order( oid => '1234567' );
>  $order->fetch();
>  foreach my $order_line ( $order->Lines ) {
>    print $order_line->Description, $order_line->Price;
>  }
>  
>  I'd like to interact with a database, update data, save data, etc.  without
>  having to actually call any SQL code.  And, if I modify my database schema,
>  I'd like the classes to automatically adapt.
>  
>  The way I've done this before, is create a series of classes with AUTOLOAD
>  subs in them which intercept the name of the method being called, and then
>  updating that specific field in the record.
>  
>  How I"d like to implement it would be to define an XML file with represents
>  the way my data is structured in the database.  This way, the objects can
>  determine when to cache data, and when to commit its values to the database
>  for maximum efficiency.  An example could be:
>  <schema name="mp3_site" database="DB0" database_vendor="Oracle"
>  database_version="8.1.5" username="nachbaur" password="you_wish">
>      <table name="artist" primary_key="id">
>          <field name="name" type="varchar" size="256" options="not null"> 
>      </table>
>      <table name="album" primary_key="id">
>          <field name="parent_id" references="artist" options="not null"/> 
>          <field name="name" type="varchar" size="256"  options="not null"/> 
>          <field name="image" type="varchar" size="4000" /> 
>      </table>
>      <table name="track" primary_key="id">
>          <field name="parent_id" references="album" options="not null"/> 
>          <field name="name" type="varchar" size="256"  options="not null"/> 
>          <field name="filename" type="varchar" size="4000"/> 
>          <field name="filesize" type="integer"/> 
>      </table>
>  </schema>
>  
>  Now, obviously thats not that perfect of an example (but I"m in a hurry,
>  'cause I need to go get some coffee), but it illustrates that the class could
>  import that XML file, which defines the way it should interpret data.  So, it
>  could fetch a particular record, and depending on how you tell it to operate,
>  it could suck down all the data that the inital record refers to, or could
>  retrieve it as-needed.
>  
>  It may not operate as efficiently as possible by default, but would give much
>  more flexibility to the programmer.  I know that when I'm lazy, I don't want
>  to bind all my values, and make sure I'm using optimized SQL statements
>  (explain plan, and that sorta thing).  With this, I could "pre-define" SQL
>  statements in this XML file that are pre-optimized, and I can just say:
>  $db->run('do_really_scarry_join', %options);
>  
>  Sory for the long message.  Would anyone like a module like this, or would I
>  be just wasting my time? Anyone already have something like this?  Any
>  feedback would be appreciated (except flames and spam).
>  
>  --man
>  Michael A. Nachbaur (KE6WIA)
>  mike(at)nachbaur(dot)com
>  http://www.nachbaur.com
>  "Only two things are infinite, the universe and human stupidity, and I'm not
>  sure about the former." - Albert Einstein

-- 
Jason Bodnar + jbodnar@[...].com + Team Linux

Oh, well, of course, everything looks bad if you remember it.

                -- Homer Simpson
                   El Viaje Misterioso de Nuestro Homer