Giving that you are trying to improve source-code management, as opposed to speed or configurability, I would move the static code into a proper module. You say that it is unlikely that other developers will need your code, but I would be surprised if such a large amount of code went into only one of *your* programs. Surprise aside, your code will be more testable with a 'use'able division for your tests to hook.

And yes, I said 'code', not 'data'. Your technique of assigning ordered fieldnames to positional data is excellent, but since those fieldnames have no independent use outside your code, I would treat them as code (to be stored in modules) instead of data (to be stored in a database or flat files).

Your first option, 'do/require', is not very different from a module with a bad interface, so I would skip the 'do' stage and go straight to a proper module. As long as you remain in single program/programmer mode, you can freely evolve the interface, piecemeal, from bad to great. See Perl Best Practices for great API advice.

As a proof of concept, I built a simple module implementing a basic (and bad) interface. I used h2xs because it is core Perl, but would use ModuleMaker or Module::Starter in real life. 

$ h2xs -A -B -C -X -n SirBones::PerlMonks::Static_Data
$ cd                  SirBones-PerlMonks-Static_Data
$ edit            lib/SirBones/PerlMonks/Static_Data.pm
$ edit              t/SirBones-PerlMonks-Static_Data.t
$ prove -Ilib       t/SirBones-PerlMonks-Static_Data.t

[download]

In the .t file, I changed the tests from '=> 1' to '=> 2', and added:

use SirBones::PerlMonks::Static_Data 'status_data';
is( status_data('dev2')->[2], 'UV_condition', '%status dev2' );

[download]

In the .pm file, I change the EXPORT_OK line to:

our @EXPORT_OK = ( 'status_data' );

[download]
and added this just before the '1;' :
our %status = (
  'dev1'  =>  [ qw(
    enabled
    crit_fault
    warning_fault
  )  ],
                    
  'dev2'  =>  [ qw(
    power_on
    OV_condition
    UV_condition
    phase_fault
  )  ],
);
sub status_data {
    my ( $device ) = @_;
    return $status{$device};
}

[download]

All (OK, both) tests passed.

In reply to Re: Best Practice for Lots of Static Data by Util
in thread Best Practice for Lots of Static Data by SirBones

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.