In a web programming environment, what are the uses of a hashtable Vs other datastructures handling Key,Value pairs

Question

I have heard of people using them for keeping track of session variables, but I really want to know if there are many uses for them and under what conditions it would be beneficial to employ a hashtable vs any other data structure that can handle key value pairs, like a dictionary for example.

eg. I have heard of people putting session values in a hashtable then putting the hash table in the Session object. I just wanted to know what benefit that was.
- Is it more performant? - Does it protect against other developers putting same name variable into the session?

Edited.

Answer 1

Depends what you mean by hash tables, for example the backend databases that drive most websites have multiple hash tables embedded into the tables (in the form of indices). Assigning data to user id's through session variables also comes to mind (or cookies for that matter). There's plenty of examples of hash table uses.

Answer 2

The framework I am currently developing will have a lot of socket requests, many a minute per client.

Each socket request will contain the client's identifier, which will be stored/looked up in the Hashtable.

The reason I have chosen to go down this route is the performance flexibility available through the Hashtable, which I will be able to leave for now - and tweak later on.

:)

Answer 3

Its like asking what is the use of hammer in construction of a house... if you want it simple then hashtable just key/value pair, its up to u where to place your nail :)

Answer 4

A difficult question to answer, mainly because you're looking for a problem to match a solution rather than the other way around. I'll throw in my two cents though.

Session variables essentially store information for the current user's session. They're accessed by a key, so they really behave in the same way as a hashtable. They may even be implemented under the covers (partly) as a hashtable - I don't know.

The important thing to note about session variables is that they are an abstraction from the fact that web applications are stateless. What actually happens is that you save a value to session, and when you return the page, that value is saved somewhere (usually in memory or a database). The next time a request comes from that person, the variable is reloaded.

Hashtables are useful mainly for fast access to a large number of objects or values using lookup keys. Because web is stateless, and session is confined to a single user, I can't see much use for hashtables. If you need to quickly get access to a piece of data in a large collection, storing an entire hashtable at the end of a request and reloading it at the start of a request just to get quick access to an item is unlikely to be an efficient use of resources.

Answer 5

Try reading Wikipedia's definition of a hash table for ideas on how you might use them.

In essence, a hash table is a way of mapping a particular key to a particular value. So in the case of session variables, you might use the variable as a key and a user's ID as the value. This would allow you to map any actions taken on a particular session to a specific user (the one logged into that session) and attribute any actions to them. Again, Wikipedia has some more information on sessions.

Answer 6

Note that "dictionary" and "hash table" are at two different levels of abstraction. A dictionary is something that maps keys of arbitrary type to values. A hash table is one way to implement a dictionary.

Note that sometimes "hash[ table]" is used as a synonym of "dictionary", such as in Perl's %hashes.

You use a hash table when you want the performance characteristics of a hash table. Mostly you wouldn't care and would just leave it as an implementation detail of your programming language.

Note that you can implement a hash table to have (amortized randomized expected) O(1) worst case, but many implementations don't go through all the work and performance overhead to achieve that. You don't need to bother if your inputs are cryptographic hashes or outright random, as in your example of (good) session tokens, so a hash table could have less overhead as compared to a hash table implementing an arbitrary dictionary.