A question of style: Composite keys to multiple valuesby Voronich (Hermit)
|on Aug 06, 2012 at 18:46 UTC||Need Help??|
Voronich has asked for the
wisdom of the Perl Monks concerning the following question:
Day 1: There's a driver table that has four columns. (note: that's a lie, but a useful one.)
I retrieve rather a lot of data from someplace. It comes in with External Name and Value fields. But we don't want to deal with the 'External_*' values. Instead they need to be translated to their internal equivalents. For instance we could have:
and a data row would some in with "GLD_SPT,PX_VALUE" and I need to translate those to "Gold,Price" before sending the data down the pipe line.
But I REALLY don't want to be tagging the database for every row as I iterate across the set (which notably does NOT come from a database.) It's remarkably stupid given the volume. No problem, preload.
So I preloaded a hash with the following(ish.)
and it actually works surprisingly well. For every row of data I get, I smack together a composite key and resolve it to Internal Name. The lookup table is prefetched. All happy nice nice.
Day 2: You should've seen this coming because it always happens to you. Yeah ok. But we need Internal_Value now as well....by tomorrow.
Ok, "by tomorrow" means add a parallel "%Value_Resolver" with the same composite string key that resolves to Internal_Value. It (of course) prefetches on the same load as the other hash.
And... sure. It works. But the whole approach makes me want to disavow it. The right "value" should be a simple list (or sub-hash? seems unnecessary) containing both values. But using a "two strings smacked together" key just seems wrong. I'm just not sure what would ACTUALLY be simpler (for values of 'simpler' approximating "easier for a programmer to understand.")
I'm in the peculiar position of being able to spend a (very) little time refactoring this code and cleaning it up a bit.
EDIT: Been a while. I forget people can't read my mind for the rest of the context on these things. Hopefully this is a bit more clear.