john.goor has asked for the wisdom of the Perl Monks concerning the following question:

Hi fellow meditators,

Anyone can tell me how I can create an OO 'layer' on top of a database package?

Example:

When I want to use a method to set a propery (in a home-brew OO package), that value should be written 'on the fly' to a database.
So I want the database connection to be persistent, for performance reasons.
What would that code look like?

I'd be *very* happy if I could get some 'turnkey' code, as I do not have too much time for lab-situations.
It does not have to be as crappy as the OO-tutotial stuff to 'point things out'.
It just has to be 'good' en 'usable', the comments will speak for itselves. I already am reading tutorials, so that's an ongoing process for the next couple of spare-hours :-)
If I did not make myself clear, do not hesitate to ask for more information on my intentions.
I will follow this thread closely.

Thanx (again) guys,
Rgds,
John

Replies are listed 'Best First'.
Re: OO and databases
by davido (Cardinal) on Jul 20, 2004 at 06:08 UTC
      Yuck!
Re: OO and databases
by jZed (Prior) on Jul 20, 2004 at 06:27 UTC
Re: OO and databases
by blokhead (Monsignor) on Jul 20, 2004 at 06:30 UTC
    Shameless/shameful plug:

    An alternative is Class::Tables. The entire idea is to get up and running in two lines.

    blokhead

Re: OO and databases
by NetWallah (Canon) on Jul 20, 2004 at 06:10 UTC
    Have a look at Class::DBI.

        Earth first! (We'll rob the other planets later)

Re: OO and databases
by john.goor (Acolyte) on Jul 20, 2004 at 13:11 UTC
    Thanx all.
    I managed to set up a working DBI interface without a flaw. Win32::OLE and Win32::ADO is now obscured by DBI, which is fine.

    I would like to know which option you guys prefer:
    Class::DBI or Class:Tables.
    Both look nice options. Class::Table however is the most easiest, but I would like to know which one is to be preferred for a production environment.
    Please advice me on this. Maybe It'll end in an interesting discussion :-).
    Why should I choose either the Class or Table variant?
Re: OO and databases
by john.goor (Acolyte) on Jul 20, 2004 at 07:01 UTC
    Oops!
    I forgot to mention that I am bound to the fabulous product made by some firm called 'Microsoft' or something.
    Which means the Class::Table (which looks very nice b.t.w.) is no option.
    Also until now I used Win32 and ADO to connect.
    Reading this, is there still an option left?
    Rgds,
    Bill's victim :-)

      DBI is not especially fussy about which database you use behind the scenes.

      I'd just try using one of the ODBC interfaces, preferably the DBI version DBD::ODBC (rather than Win32::ODBC) or I notice that there is a DBD::ADO available. Also, DBIx::SQLEngine may be of some use. Not used any of these, so this is not a recommendation, just some pointers to more info.

      Hope that this helps.

      Cheers,

      -- Dave :-)


      $q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print
      I think you really should give DBI a try, because it's the de facto standard database interface for perl, so it's probably better supported. Also, it will be easier to switch to other databases and you can reuse more code. It's not all that different from ODBC, so it shouldn't take you too long to learn.

      I'm not 100% sure that Class::DBI supports DBD::ODBC (the DBD::XXX modules are the database sepecific drivers for DBI) but in theory most of it should work. Give it a try. If it doesn't work, ask the Class::DBI mailinglist. they're a helpful bunch of people.

      Cheers,
      Joost.

      In addition to DBD::ODBC, you can also use DBD::Sybase to connect to SQL*Server. It so happens that Microsoft chose to build SQL*Server from Sybase 4.3. :-)

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested