in reply to Hash tables, are they really what we see?
The analogy that I use for hashes is that of a set of post-office boxes ... which, for the purposes of the analogy, might be shared among a number of different people. Based on what the envelope of the incoming piece of mail says, it will always be placed into only one box. When someone comes to ask for their mail, you’ll look only in that box, but you still might have to look through the contents of that one box to find what you’re looking for.
Some database systems have been built which do provide “hash” indexes. They are fast and efficient, provided that both the data-distribution and the hash function h() are such that there are not an excessive number of collisions ... where too-much mail winds up in the same box.
Hash structures are low-maintenance, but they are also random-access-only. You can’t iterate through values naturally in key-order. (Although a hash-variable that is tied to a Berkeley-DB file will yield its contents in key-order to each().) Hashes do not require the rebalancing steps that are required by trees. They are so useful, and therfore so often used, that every major language now has a rock-solid high performance implementation of them.