I quite often have data sets where I have "keys" but no values. Only the fact that a "key" is present is important. If this set gets me unique keys, and the keys are all numeric and smallish, the choice is easy ("select c_foo from bar where c_foo < 1000 and bummer > 4"). But what if c_foo is a not unique (like I want to do something with foo for all keys appearing in some other dataset not necessarily from a database)? If I want to count the number of c_foo occurrences, a hash is of course the way to go: the count is the value to the key c_foo. However I quite often have to deal with foo for a slightly different query: "select c_foo from bar where c_foo < 1000 and bummer > 4 order by glome" where the order matters and c_foo is not unique. In this case, an array is the way to go. Of course one can store the data in a hash and keep the index in the value or - for easier perusal, store the index in the key and the key in the value, but that is very counterintuitive. Hence I do not think the first two are moot in this discussion: it is all about when to decide to use a hash or an array. In most cases both can be used but not always as efficient. That means both ways: efficient to maintain (and read 6 months later) and efficient in performance or memory.