in reply to How to define and deref hash of hash of hash

Hi again dirtdog,

Great advice above from kcott about doing some reading, but you must be feeling frustrated that the advice has come full circle and now you are being told to use arrays instead of hashes! This is because you are describing your sub-tasks and getting advice on each, when what you may really need is advice on how to tackle your overall task. This is sometimes called an XY Problem, as in, your real problem is X but you are asking about Y because you've assumed that's the right approach.

So, maybe you would like to explain a bit about your overall goal: it may elicit different and more applicable advice. For example, now that I see that you have a configuration section for restaurants as well as sports teams, my advice may have been different: I would have probably suggested using YAML, or an .ini file or some other format that would allow you to maintain your data in discrete sections easily outside your program code.


The way forward always starts with a minimal test.
  • Comment on Re: How to define and deref hash of hash of hash

Replies are listed 'Best First'.
Re^2: How to define and deref hash of hash of hash
by Marshall (Canon) on Feb 09, 2017 at 01:35 UTC
    Good comments from 1nickt++. Also good replies from kcott and others.

    If the OP's main goal is just to learn about complicated hash data structures, then I think there is lot's of info in this thread.

    If the OP's goal is to implement some sort of DB application that will "live" and be maintained over time, I think the advice will differ significantly. One point is how add/modify/delete records easily without modifying the actual Perl code. Another consideration might be the difficulty or ease of adding new sections of parameters to existing records. Maybe add NHL for example.

    Some sort of YAML or .ini file for data input is certainly a possibility.There are others.

    What sort of queries do you want to do on this DB that would be useful in an application sense? I have currently no idea. Teams and Restaurants don't seem to have anything to do with each other unless there is some linkage to which ones are near which parks?

    Rather than some complicated HoHoHoH structure, this sounds to me more like an SQlite DB would yield far more flexibly in querying the DB. Just a thought. The combination of a simple DB DQL query coupled with some extra PERL processing can be very powerful.