I'm developing an application where in there are 3 different set of users: admin,manager,employee.
I intend to have a single log in page for all users.
based on the credentials different users will be shown different pages.
is this a good idea?
Also how do i go about designing db?
I have created "roles" table with roles_id(primary_key) and role_name
what next
Yes its best to keep everything as simple and uniform as possible. Therefore I would agree that a single login page, irrespective of type of user is a good idea.
Within the table that you store the users details in an additional field that designates what type of user would be adequate. That could be the foreign key to the roles table where you provide detail of what each role can do.
Related
I would like to use the mysql role provider for aspnet. I have setup a custom table for the users using the attribute userTableName="user". Now the problem is that when I assign users to roles, MYSQLRolesprovider creates an entry in a table "my_aspnet_usersinroles" which and "my_aspnet_users". I would like to specify that the table used to specify roles should be the "user" table. How do I do that? Do I need to write a custom role provider? Is there a setting that I can tweak to make that association? Or am I just using this whole system wrong? Thanks
specify that the table used to specify roles should be the "user"
table.
If you want Membership Provider to use your User table, you need to implement Custom Membership Provider.
Custom Membership Provider requires a lot of work especially if you are new to Membership Provider and Provider Model.
Alternative Approach
Use FormAuthentication if you do not need Membership Provider's all features.
OR
create UserId in User tables as PrimaryKey as well as ForeignKey like the following. (One draw back in this approach is you can only use in new application; you cannot implement in existing database.)
You need separate tables for users and their roles. Generally, it's three in total, one for the users, one for the roles, and one to tie a user with one or more roles. The usersinroles table allows the one to many relationship so your user can have more than one role. Also, good database design would dictate this as well as the user table should only contain artifacts directly related to the user itself.
I am working on a Project where I have below use case.
User can have many taglines for them , we have lot of predefined data in the DB which we using to show autosuggestion when they started typing tag lines, I am using Rails.
User has_and_belongs_to_many taglines
Tagline has_and_belongs_to_many users
I have separate joint table and everything was fine , but now I need to store custom taglines of user to DB , which will be belongs to only particular user.
Should I clone the taglines table and add user ID to it Or what is the best architecture to handle these kind of scenario , if we have more than one model which have same use case as like taglines.
your existing user and tagline table has many-to-many relationship, keep it that way. Whereas the user table and the new customTagline has a one-to-many relationship so why don't you create a new table to represent it? Since you mentioned the customTagline belongs to only a particular user.
#BroiSatse Comment make sense, I followed same.
If you create a second table, you will need to remember to update two
tables/models every time you will want to change your model. You won;t
be able to pull all the user tags in one go neither. many-to-many is
able to hold one-to-many association. Just add a validation to check
that given tag can belong to only one user if it is custom.
Should you create a table for each user to contain information on specific content for an account, say favorite articles, interests, ect. User defined lists that would be used to generate useful content using a tag system to define groups of content. Would i be approaching this close to right, or is there a better way. i know u should not define more than one thing in a column, but i also would want the fewest number tables too? is there a way to use a table for all users to store info in such a manner?
Ideally your the number of tables in your database should not depend on the number of users. Have a table of for the users and another table for preferences with a foreign key to the users table.
I am creating a simple web application.
Is it wrong to identify user by it's user name even in the application low level?
For example, say I have a authentication token table that has three columns: token, userID, expDate.
Will it be wrong to put the user username in userID column?
Do I have to worry about the fact that everybody knows the user ID in my DB?
No, I don't think there's anything wrong with that particularly. I've seen that in practice at very big sites - just make sure that you have a unique constraint and index for that value (better, make it the primary key). Also, consider that using the username as their ID means you can't let the user change their username later without breaking existing links (say, if your user shares their user page externally).
I'm not sure, but there might be some overhead from using a string instead of a number.
Also it could be a hassle to update other database tables if a user's username ever changes.
I am using Ruby on Rails 3 and MySQL.
In my project I would like to create an activity-stream "module" in order to save each user action information in a dedicated user table. That is, to create a database table for each user.
Is it a good approach to create a database table for each (new registered) user in my application?
No, it is not a good approach. Why would you create a separate tables with all the same fields? Just add user_id to your table and store all info for every user in there.
I do something similar, and it's not necessary to create a whole table for each user. For example, I have a table called "user_actions", and in it there is a column, "user_id".
The relationships are:
User has_many :user_actions
UserAction belongs_to :user
And you're done. Let the foreign-key relationship that comes naturally take care tying the specific action to a specific user.
Once you do that, you only need to decide:
Which actions cause an entry to be added?
How long should you retain the data (1 week, 6 months)?
For example, on my site, I keep a log of the last 5 things a user viewed, and present that list to them on a section of the page called "Recently viewed items" for convenience.
I also have a separate table called "admin_actions" that I use for security logging that keeps track of everything done under an admin account, and what admin account made what sort of change.
I guess the answer is that it depends on how many users there are. If it's not a small, defined number then I'd suggest that it's not a good idea to create one table per user.
I'd suggest a single table with one column being a unique identifier for the user. Make sure that whenever you're querying the table that you're using an index that has this column as the first column in the key. E.g. PRIMARY KEY(user_id, activity_time)
This should allow for fast and efficient reading of the rows.