Storing user variables in database vs session in asp.net

Question

I'm working with an asp.net application that stores most data in a database and not session. I'm wondering of the pros and cons of each and which is the better way to go. For example, you have a pretty busy site and instead of storing user specific variables in session, there is a DB table called user data and it can store all user specific data that can be accessed from any page by querying the database. Which is the better way to go, session or database?

Answer 1

Session (but it depends a lot of the session configuration) :

• No database access, or less.
• Temporary storage : you may lose the information, at least when the session ends.
• Maybe some security issue, depending on where you store the session information
• Not shared : you may have issues if you're using a server farm, one server may not have access to the other server session.
• May not work if the client disabled the cookies.

Database :

• Database traffic for each postback if you need the information on each page.
• Permanent storage.
• No information stored with the client (cookies...).
• Shared : data accessible from any server on a web farm.

Please note that you can store Session information in database. That's why I use the word "may" in the Session part. See here some session configuration and possibilities

Answer 2

Anything stored in session state will vanish when the AppDomain is reset.

You could avoid that by using an out-of-proc session state handler, but that's no better than a database.

Answer 3

Interesting question. If it's data that's not important across sessions (say, last page viewed) -> session. If it's data that should be persistent (say, password) -> database. The interesting case and the one you probably refer to: Data that should be persistent but is also used often (say, the username). From these, I tend to copy those values from the DB into the session that allow me to work without database access in pages with trivial tasks.

Answer 4

In many cases, I use Session to store temporary data about the... well... "session". In ASP.NET, session is configurable. You can use in-proc (default) which uses the server's memory. You can also configure session to use a database or a session management tool (in case server memory is a problem or you move to a cluster/farm environment).

Session is meant to be temporary. This is great when you are truly storing data about the user who is using your application at that moment. When the user leaves the app and his/her session expires, the memory is freed up. You don't have to manually clear anything out.

Session uses the server's memory. As long as you have enough memory and you're not on a server cluster, this works great. Memory is fast, so getting and setting data in session is very fast and uses zero network bandwidth.

Have said all that, in a few of my apps, I have session configured to use SQL. It's basically the same as using the database directly, but I don't have to deal with DAL... just let the framework work for you.