views:

47

answers:

3

In my ASP.NET MVC application I allow users to log in. Each user is associated with a company. Company ID and company data is not part of the Users table in the database. User and Company are connected through a related table (one to many relationship). Company ID is not part of the Users table as a foreign key because the design of the Users table did not predict that and we are not allowed to change it.

When user logs on we want to take the company ID for this user and store it somewhere. We would use this ID later for querying and other kinds of filtering by company because the content is stored per company.

Where should I store the company ID setting to make it persistant over many web request?

+1  A: 

Maybe this sounds so stupid but.. what about storing the info into an object and putting that object in the session?

Jesus Rodriguez
I am using the session currently. So that is one option. I am looking for other options also.
mare
A: 

Most people use Session or Cookies for this type of functionality:

Can't answer any better than the answers in this question:

http://stackoverflow.com/questions/553185/cache-vs-session-vs-cookies

jfar
+2  A: 

I see three viable options

  • Session

  • Cookie
    This may or may not be in the authentication cookie, your choice.

  • Keep it in the database
    Query as and when needed. If it's needed less than x% of the time, just fetch it as and when needed from the datasource.

Russ Cam
I would vote for "Keep it in the database" for performance reasons alone.
Chris Lively
I eventually decided to go with Session but to store it in SQL Server for the sake of reliability.
mare
@mare- does that offer any advantage over having it in the database, if your using SQL server based session storage?
Russ Cam
For me the advantage is that I used aspnet_regsql to create the two Session tables in my database and when setting up the correct connection string in web.config I am able to use the builtin SQL Session state provider and that has saved me from writing a single line of code for Session management.
mare
@mare - what I mean though is that the value is coming from a database originally, is put into session, which is database backed. Each time it is needed from session, a database call needs to be made, which doesn't seem to yield any advantage over retrieving it from where it is originally stored.
Russ Cam