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).