Despite the performance hit, it is a stable hit. A hash lookup is done in O(1) time. An indexed database lookup can also be O(1). What I just said is a little misleading; Remember that big-O notation refers to order of growth based on growth of the dataset. But big-O notation doesn't deal with the fact that making one trip to the corner store takes less time than making one trip to the mall five miles away. So it's true that a hash lookup will be faster than a database lookup, but the important thing to remember is that order of growth is about the same. In the case of a hash lookup, there's essentially no growth in lookup time as the dataset grows. In the case of an indexed database, the same can be said, although the actual time will be longer for the database.
But where I'm going with all this is that if you are forced to the realization that memory constraints won't permit two hashes to be held in memory in tandem, it's time to start making tradeoffs. And one of the more common ways of lending scalability to a problem is turning to a database solution.
Dave
In reply to Re^5: two hashes occupying the same space
by davido
in thread two hashes occupying the same space
by jfroebe
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |