Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I am a newbie so please forgive my question. I have plotted an Oracle database successfully, however my boss wants me to use different scripts for creating the table, dropping the table and plotting the table. I'm a little confused in how to do this...will these scripts just create the sql in text, but then how do I send it to the original script? Do I need to connect to the database with each of these scripts? Thanks for any help

edited: Thu Dec 26 18:33:12 2002 by jeffa - title change (was: creating cleaner code)

Replies are listed 'Best First'.
Re: modularizing database script?
by gjb (Vicar) on Dec 26, 2002 at 16:52 UTC
Re: modularizing database script?
by pg (Canon) on Dec 26, 2002 at 17:27 UTC
    I looked at your code, and yes, I want to suggest a different way, to organize them.

    Generally speaking, I don't like to mix data with code. In your case, I would look at your sql statements as data, when I take your Perl scripts as code.

    But I don't agree with your boss, if you understood his idea correctly, that you have to put each(?) of those statements into one(?) script. That would become a even bigger mess. After one month, probably nobody, even yourself can quickly figure out which script is for which sql statement any more.

    I would suggest you to have a separate package, which you can call it SQLBuilder. If you want to impress your boss more, do it in OO-style.

    The main function of this package is to build sql statement as instructed by you, and return the sql statement as a string. You should contain all the syntax details in this package, do it once forever.

    Another benefit of this approach is that, it makes your code more portable. What I realized in the past is that, the sql syntax is actually slightly different from database to database, as they all support some sort of their own extension. If you want to port your script to a different database one day in the future, the sql syntax changes will be contained in this package, instead of spreaded everywhere.
Re: modularizing database script?
by Aristotle (Chancellor) on Dec 26, 2002 at 16:36 UTC
    You need to provide more context - your question is so vague it's nearly impossible to answer as is. Preferrably post a (short!) snippet of code showing the essential bits of how you currently talk to your database and explain the tasks you'd need to implement a bit clearer.

    Makeshifts last the longest.

      Here is my code:
      my $dbh= DBI->connect("DBI:Oracle:", "scott", "tiger") or die $DBI::e +rrstr; my $sth1= $dbh->prepare(q{truncate table directory_data}) or die $DBI: +:errstr; $sth1->execute or die $sth1->errstr; my $sth = $dbh->prepare(q{ INSERT INTO directory_data(dn, cn, surname, given_name, initials, +generational_qualifier, building, room_number, mailstop, telephone, fax, mail, tfs_id, uid) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?)}) or die $dbh->errstr; foreach $emp (keys %employee){ $sth->execute($employee{$emp},.,....)
      Currently I have created the Oracle table using SQL Plus. I would like to,however,create the table using a different perl script that I call within this script. Also each time I call the original script I want it to drop the current table and plot the new information. I would like to perform these sql functions in a different script as well. I was told that creating these different scripts will clean up my code. I hope this clarifies my question and again thanks for any help.
        Spreading your code out among several different files won't really clean up your code ... it will just spread it out among several different files. :)

        What you need to do is search the CPAN for some modules that will make your task easier ... modules like DBIx::Connect which will allow you to abstract the DB connect info out of your scripts (and into a config file). However, before i start ripping my one script into a modularized, maintainable package ... i'd clean up what you have. Here is how i would code your snippet:

        my $dbh = DBI->connect( qw(DBI:Oracle: user pass), {RaiseError => 1}, ); # with RaiseError turned on, no need for die and errstr $dbh->do("truncate table directory_data"); my $sth = $dbh->prepare(q{ INSERT INTO directory_data( dn, cn, surname, given_name, initials, generational_qualifier, building, room_number, mailstop, telephone, fax, mail, tfs_id, uid ) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?) }); $sth->execute($employee{$_},.,....) for keys %employee;
        Sometimes i like to use code to generate an INSERT statement:
        my @field = qw( dn cn surname given_name initials generational_qualifier building room_number mailstop telephone fax mail tfs_id uid ); my $table = 'directory_data'; my $sql = "insert into $table (" . join(',', @field) . ') values (' . join(',', map '?', @field) . ')' ;
        You could turn that snippet into a subroutine and pass it the name of the table, an reference to an array of field (column) names, and a reference to another array that contains the values (just make sure the two arrays line up!).

        Hope this helps and gives you some ideas. :)

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        

        If you want to further 'abstract' your code DBIx::Recordset is worth having a look at.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        Why would you want to create the table using a different perl script???

        Your truncate will delete all the data... do you need to run the script somewhere where the table does not exist?

        I think that having one script will make your code cleaner... since this seems like a small script... no need to spread all the code in different files... How about splitting it in different subroutines?

        you would probably want to replace the truncate by a drop and a create, but I don't think it's a good idea to do so in Oracle... (Will the table be in a separate Tablespace? How will extents allocation go, How frequently will you do this... it depends on so many factors)