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

Fellow Monks,

This is more a question of style than anything. I have a hash of field positions(i.e. 1,9,13) which hash to the length of the field starting at the position represented by the hashkey. Example

my %positions = (1 => 8, 9 => 11, 20 => 2, 22 => 9, 31 => 7, 38 => 8, 46 => 8, 54 => 8, 62 => 30, 92 => 12, 104 => 30);
These are client specific. This scipt will run to extract data from data received by different clients, the client will be selected by the user.

My quandry is this...where do I store the field positions and their lengths? My initial though was to have a database table setup with two fields: starting position and length. I could then query those out and put them into a sorted hash. The more I got to thinking about it. I didn't want to put stress on the database(albeit small) and re-construct those hashes everytime. Is there a way that I can have the hash pre-constructed in a seperate file and import the hash into my main program based on the user selection?

Which way is better? Does the trouble of managing seperate files outweigh the load on the database and the run time of the script? Or is their some slick foo-cantation that,unbeknownst to me, will make this easier

Thanks for your input,

Grygonos

Replies are listed 'Best First'.
Re: Managing Client Specific Hashes
by Corion (Patriarch) on Jan 13, 2004 at 14:59 UTC

    If the fields are always in the same order, some magic unpack could reduce the complete hash into one string. Otherwise, I would simply put each client into a different file that declares the same package, and load the "right" package from the command line:

    ### main script: die "No client data specified" unless %Client::Data::positions; while (<>) { print decode_positions( $_, %Client::Data::positions ); }; ### client/Client/Acme.pm package Client::Data; use vars qw(%positions); %positions = ( ... ); 1; ### command line perl -MClient::ACME magicscript.pl
    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
Re: Managing Client Specific Hashes
by Abigail-II (Bishop) on Jan 13, 2004 at 15:01 UTC
    I could then query those out and put them into a sorted hash.
    What's that, a sorted hash?
    Is there a way that I can have the hash pre-constructed in a seperate file and import the hash into my main program based on the user selection?
    No, you can't dump nor load a hash "as is" to or from a file. You can dump and load the content of a hash to or from a file, but if you load it, the hash still needs to be constructed.

    You can however make use of DBM files. Then the data will stay on disk (in its own formate), and you have a tied hash as interface. Whether or not that will be faster will depend on the size of the hash, the amount of queries and updates you are performing, the speed of your memory, CPU and disk, the size of your memory, the throughput of your I/O, etc. Only by testing it under production conditions you can be certain what's faster.

    Of course, if all we are talking about is a handful of 11 entry hashes, it hardly matters which method you pick.

    Abigail

      That was a sample, the real hash is 63 elements.. nothing enormous.. but yes bigger than 11. When I say the hash is sorted I mean the keys are sorted when I use it. I know the hash itself is never really sorted.

      Grygonos
        63 elements is not much. Determining which method to load the hash is the fastest isn't worthwhile (unless you want to load thousands of them).
        When I say the hash is sorted I mean the keys are sorted when I use it.
        What do you mean by that? Does that mean you always sort the keys, and access the hash using the sorted keys? In that case, it looks like you shouldn't use a hash, but a sorted array instead.

        Abigail