in reply to Hash space/ time tradeoff
Truly, it depends on how you intend to use the data, having (in whatever fashion, by whatever means ...) collected and cataloged it. If you are constantly going to be presented with 3-tuples of specific attributes, and the only question is whether that specific 3-tuple does or does not exist, then your present strategy of using a composite key consisting of a concatenation of the three values is going to be (IMHO) the fastest thing that you can hope for.
If there are other things that you need to do with these data, especially searching on partial keys, then “a hash-table” starts to lose its lustre pretty darned quickly, and other possibilities (such as my oft-suggested “SQLite database file”) start to look pretty shiny. Of course, you can have both.
A hash-table is very-good at one, but only one, specific thing: determining whether or not an exact-match exists or not. Yes or No. Although you certainly can build multiple hashes, and in Perl you can “reference” the same data-object in multiple hashes without duplicating the actual content, the Swamp of Diminishing Returns is pretty deep. Be careful to step back and take a good hard look at the whole big-picture. Hash-tables are a fantastic-performance, but extremely special-purpose, data structure. (And Perl’s implementation of them is second to none.)