Question

Here’s the layout:

• I’m developing an internal ASP.NET Web App (in VB.NET) with an SQL Server Database.
• Since my users are strictly internal, I’m using the “Windows” method for automatic authentication.
• I have four user Roles, each with their own very unique, and dynamic, set of settings.
• BONUS: Each user may have multiple Roles and hence multiple Profiles.

From my extensive research I have determined the following two methods for storing user profile settings (both of which prompting the question “HOW?”), though I’m not sure which is best (if any):

• Store profiles and associated settings in the DB (Using what structure? From preliminary mapping, I’ve created at least four tables which is starting to get grossly unmanageable and unmaintainable)
• Use the built-in ASP.NET Membership & Profile object? (I can’t seem to find a good tutorial on this. Does this method still require DB support? Again, using what table structure?) –I’m most interested in this possible solution

Example:

My most complex user group requires the ability to store a profile of all (user-selected) products associated with the user. Say I’m a product manager and I want my account to show me all the products that I’ve selected for which I am responsible. Obviously each member of my role would have different products and a different quantity of them, etc. Perhaps user page settings (e.g. search, sortation, order defaults, etc) could be stored in a generic table, with a reference to an auxillary settings table for the weird stuff which can be linked to through a special record which could act as a “foreign key” of sorts.

As Requested, one of my ideas for a table plan:

    Users (ID, Username, RoleID)
    Roles (ID, RoleName, Description) --Lookup Table
    Settings (ID, Name, Value)
    UserSettings (ID, UserID, SettingID) --Junction Table

Then the questions arise:

1. When should I use a row vs a column?
2. If I use a column per setting I can define datatypes, but column count could get out of control. On the other hand if I use a row per setting it makes much better sense, but I lose control over the data type for the setting.
3. Should I omit the UserSettings table and just append a name=value pair record for each setting in the Settings table with a UserID foreign key instead?
4. etc etc…

My Ideal Answer:

As you can see I have many questions and have found seemingly little help. I would LOVE it if someone could break it down for me in simple terms. Please tell me your professional recommendations and some super simple tips on how to implement it (i.e. which ASP.NET objects to use, as well as how said objects provide the mechanism for managing my complex profiles)

Answer 1

I think this almost certainly needs to be modeled in the database.

The products associated with a user would not really be a role-based thing – so would have to be largely independent of the role even though you say only managers would have that relationship. Only users in a role would have that linkage, but that’s kind of a high-level restriction you might enforce at the application level or some higher level constraint – not with a foreign key – unless you had a linkage which depended upon user and role.

Then a user acting as manager might have certain products, but acting as a salesman, different products. Then the role would be in the link table as well. Sometimes link table rows do have attributes about the linkage, not just the linkage themselves (usually things like effective dates and active/disabled flags).