in reply to Effective data structures for join-type lookups

If you can install Perl, you can also install DBD::SQLite, which contains SQLite already.

You can also install DBD::CSV, which will do SQL over CSV files.

If you are all averse against installing modules, just use a hash of arrayrefs, where each hash contains as keys the join criteria for one table.

Basically, have your tables as arrays, and store in the hashe values the row indices for each row, and as keys use the join criteria.

I still recommend going with DBD::SQLite.

  • Comment on Re: Effective data structures for join-type lookups

Replies are listed 'Best First'.
Re^2: Effective data structures for join-type lookups
by flightdm (Acolyte) on Oct 03, 2016 at 22:20 UTC

    Thanks, Corion. Perl and Python are already on - otherwise I'd be having nightmares about JS, ugh - but yeah, installing anything more would be like dentistry. On black mambas. Without anesthetic or restraints. Straight Perl is best, methinks.

    And I think you've got me shifted onto the right track: I'll have to reformat the second table to make it work as you describe... which was the key to solving the whole thing. Like so:

    # From this -
weight     area    cost
1              2          3.17
2              2          3.87
3              2          4.51
4              2          5.22

# To THIS:
$cost{2} = {
                      1     => 3.17,
                      2     => 3.87,
                      3     => 4.51,
                      4     => 5.22,
                      [...]
};

    [download]
    at which point, it solves itself. Thanks tons!
[reply]
[d/l]

      This does sound like a perfect case for an embedded app in JS. Would work on disconnected laptops, phones, or tablets. HTML5 has SQLite support native. JS isn’t so bad and it’s great to have chops in it.

      There are a few Perl tools to help build such a thing. Static DB could be dumped from source SQL or other flat data via JSON for example.

[reply]

        I'm sure you're right - it probably would be great from that perspective. It's that "having chops" thing that's a bit problematic... although I've learned many of the languages that I know "on spec" - i.e., because they were needed for a specific job - learning JS just to code one little app like that would a bit much. :)

        Interesting to know about native SQLite support in HTML5 - thanks!
[reply]

      Since at least 7 of your users will have to "install" your little app on their laptops, you could use the fatpack tool (in App::FatPacker) to bundle your app and its dependencies into a single .pl file.

      Then there's the pp tool (in PAR::Packer). It can bundle your app and dependencies into an exe file. An advantage of using pp is that the exe will include its own copy of Perl. The down side to doing this is the start time is slow (because everything gets unpacked to a temporary folder each time it is run).

      pp has an option to create a Perl script. I have not tried it, so I don't know if this might be a better option.

      There is also a "par" tool in PerlPowerTools, but I'm not sure how helpful that will be. Nor was I able to install PerlPowerTools (there was a failure in one of the dependencies that I don't have time to debug), so I can't try it.

[reply]
      Sounds like you have workable solution but I'd like to point out that depending upon the Perl distribution that was used, SQLite may already be there! All of the code to use SQLite installs with DBD:SQLite.

      I use Active Perl and the DBI and SQLite ship with the distribution, so there is nothing to "install". Perhaps something to consider/investigate for future projects? Most distributions ship with a lot of modules "pre-installed". In my case there are 281 of them! SQLite is pretty ubiquitous. I've heard that every smart phone has an SQLite DB. Certainly many products such as Mozilla Firefox use it. Anyway, you might be pleasantly surprised to find SQLite already there.

[reply]

In Section Seekers of Perl Wisdom