FYI, here was my test (assuming worst case of 'not found'):

#!/usr/local/bin/perl -l -w

use strict;
use Benchmark;

my @zips = qw(
        92713
        92714
        92715
        92716
        92717
        92718
        92719
);

my $zip = '11111';

timethese (50000,{
 HASH   => \&hash_it,
 LINEAR => \&linear,
 LINEAR_GREP => \&linear_grep,
});

sub hash_it {
 my %zips;
 @zips{@zips} = undef;
 exists $zips{$zip};
}

sub linear {
 for (@zips) {
  return 1 if $_ eq $zip;
 }
 return 0;
}

sub linear_grep {
 grep { $_ eq $zip } @zips;
}
/usr/home/dougw/tst>./timeit
Benchmark: 
timing 50000 iterations of
 HASH, LINEAR, LINEAR_GREP
...

      HASH:  3 wallclock secs ( 2.65 usr +  0.01 sys =  2.66 CPU) @ 18
+796.99/s (n=50000)

    LINEAR:  1 wallclock secs ( 1.84 usr +  0.00 sys =  1.84 CPU) @ 27
+173.91/s (n=50000)

LINEAR_GREP:  0 wallclock secs ( 1.16 usr +  0.00 sys =  1.16 CPU) @ 4
+3103.45/s (n=50000)
[download]

Update:I don't include positive searches because we don't know the probability of WebSmart's users of entering a 'found' zip code. So I assume that since there's so few (5 - 10) 'valid' zip codes, and so many possible zip codes to enter, it will probably be 'not found'. Positive searches would just make the results lean more toward the LINEAR search, I don't know how many positive searches it would take before LINEAR would be better than the LINEAR_GREP. Either is better than the HASH, though.