Re^4: two hashes occupying the same space

That is a good point. However as soon as the indexes are not entirely held in memory you get a performance dropoff. And the relational database itself already is a performance decrease over a straight hash.

TANSTAAFL. Pick the trade-off which is most appropriate for what you're doing.

Comment on Re^4: two hashes occupying the same space

Replies are listed 'Best First'.
Re^5: two hashes occupying the same space by davido (Cardinal) on Oct 28, 2004 at 05:45 UTC
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	[reply]

Replies are listed 'Best First'.

Re^5: two hashes occupying the same space
by davido (Cardinal) on Oct 28, 2004 at 05:45 UTC

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

[reply]