Perl: the Markov chain saw | |
PerlMonks |
Re: Multidimensional arraysby misterperl (Pilgrim) |
on Jun 06, 2023 at 18:13 UTC ( [id://11152664]=note: print w/replies, xml ) | Need Help?? |
A birdseye view of what you're up to-
FIRST what you have looks much better suited to a hash, with the "stripe" as the key. But I'm not sure if that's really sound either because, assuming a product price can go up or down, there's no guarantee of uniqueness. You would know better. But assuming you can implement a unique key, then there are a few other things you need to consider. Thinking of your use-case, and that you might want to list prices in chronological order, you probably want a DATE TIME field. Another thing to consider is that your SET of products consists of say three durations. What if later you offer a product that is ALSO monthly, but maybe it's an ad-supported version? Well if you use duration as the only product delimiter in the hash key or in the array, now you have a potential issue. Finally, your individual hashes look like a SQL table row, with colnames = your hash keys. You'll need to consider how to store and retreive it. NORMALLY, the primary key would be just an auto_increment integer, with N more cols , one for each element in your hashes. Your "stripe" looks like a row identifier perhaps, but you may not need to store that. Normally you would not store compound-elements in your anonymous hash, or the table rows . If you needed keys like those, you can build a hash of them by reading sql query rows into a hash. In my head, SPARSE usually means I need a hash, not an array (the MORE sparse a hash is, the faster it can be searched).
In Section
Seekers of Perl Wisdom
|
|