@results = grep {
    $_->{user} eq 'Fred' and
    $_->{date} >= 1023318000 and
    $_->{date} <= 1024182000
} @$userdatefile;
[download]

Your problem seems well-suited to be treated with object-oriented techniques.

Hide your data structures into an object, and create methods to get the views you need. You could then implement methods that reorder your hash on the fly or, if memory is not an issue, implement a cache that avoid recalculation of the same hash when not needed -but that would bring you back to the cumbersome and tedious problem to create new hashes for each dimensional rework of the original dataset :-).

Let me know if I should go further and drop some quick-and-dirty code you can use as starter.

Ciao!
--bronto

# Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->made($love) ;
}

Howdy!

This answer doesn't really speak to the core issue -- the data model. See my reply below for more on my point...

yours,
Michal

You could just add the new keys to the existing hash and make the same data serve both sets of keys:

foreach my $user (keys %dateuserfile) {
    for (keys %{$dateuserfile{$user}}) {
        $dateuserfile{$_}{$user} = $dateuserfile{$user}{$_};
    }
}
[download]

Update: ichimunki, rewrite line 5 as $hash{bar}{foo} = $hash{foo}{bar};. You're copying the value by including the deepest key. Leave off that last key and you get a copy ot the reference to the hash where it lives.

After Compline,
Zaxo

Updates from one view will be seen from the other.

They will? I tried the following:

#!/usr/bin/perl -w
use strict;

my %hash;
$hash{foo}{bar}{x} = 'zoom!';
$hash{bar}{foo}{x} = $hash{foo}{bar}{x};

print "$hash{foo}{bar}{x}\n";
print "$hash{bar}{foo}{x}\n";

$hash{foo}{bar}{x} = '!mooz';

print "$hash{foo}{bar}{x}\n";
print "$hash{bar}{foo}{x}\n";
[download]

which outputs:

zoom!
zoom!
!mooz
zoom!
[download]

Now, if maybe I'm misunderstanding what your code does, but while it gives two separate views of the data, it does not create a duplicate set of references to a single set of data... if my calculations are correct it creates a second copy of the data with new references to the second copy. Changes to one copy will not affect the other.

---

update: my fault for not paying attention to details! Thanks for clarifying zaxo. Of course, this is still less than optimal, since it would seem to make doing key reordering impossible for that last key (not that doing this was in the original requirements, but it's the kind of solution I'd be hoping for). Also, we do still have a potential key overwrite going on (think $hash{foo}{foo}{x}).

George_Sherston++

Makeshifts last the longest.

I found this node referenced in the POD for Data::Hash::Flatten.

The fundamental issue is an inappropriate data structure. Given what you want to do with the data, a HoHoHoH is (as you've discovered) cumbersome for many searches.

The problem illustrates the weakness of hierarchical databases. Your data model could be restated as a relational table with four columns:

• user
• date
• file
• count

The first three items together constitute the "key"; all three are required to uniquely specify a count.

An array of hashes would be a more useful model, since each count is identified by a combination of user, date, and file. Without all three pinned down, you may have more than one "row" identified.

An array of arrays would do as well, if you don't mind giving up the symbolic "column" names.

yours,
Michael