We are running single database for rest app server. We have three types of users
for customer
for administrator, and
for partners
Currently they have different tables and username and password are also in separate respectively Now We need to refactor this schema as user are expanding.
So should a single table User with Role table is OK ? (Here Role can be admin, partner or customer, manager).
OR
Should we a keep as it is as We will be having issue if we use User and Role table:
if an admin acquire a username then that username can not be the same again for customer or partner due to unique constraint.
I think user role can not be as "Customer" as customer is not a Role. Role can be admin, manager etc
I think this is not the right way to keep in single table. What are your suggestions?
I think you should create three tables for your user management, considering the fact that one user can have several roles (ex:- admin can also be a manager Or Customer can also be a partner). So User table and Role table have a Many-To-Many relationship. In order to create this relationship, you have to create 3rd table having userId and roleId as composite primary key.
additionally, i noticed that you are going to save user's passwords in the database. For the security reasons do not store passwords in plain-text. Instaed store the hash of the password using one way hashing algorithm.
You can read more about it from here -> Best way to store password in database
Yes, it would be better to keep separate tables because of the following reasons:
1. As you specified, Customer is not a role.
2. Since administrators would be limited in number, there is no point in fetching the record for authentication/authorisation from a large data set having the customers. It will hinder the performance.
User
id
userId
role (foreign key)
etc..
Role
id
name
etc
the above structure is best practice.
if you really need extra fields for admin, partner or customer
you can create separate entity for each one and you can refer user as a foreign key like as follows
Customer
id
name
user(foreign key)
etc
Related
I was designing a database as my practice and I came across a confusion where I am not sure the cardinality between a pair of my tables – users_roles, and roles
So I was wondering if you could break it down for me and explain how to think of it to be able to define the relationship. I've got quite a lot of these intermediate tables and they are just confusing me!
Additionally, I'd like to ask if I named my intermediate table correctly.
Depends on what relationship you want to achieve.
users and roles tables are holding all the users and roles.
users_roles maps users with roles, or user id's with role id's. Both user_id and role_id are FOREIGN KEYs referencing id in the other tables as a PRIMARY KEY.
This is giving you a one-many relationship between roles and user_roles as one user can have multiple roles. You can also have one-one relationship if you make role_id UNIQUE, in this situation, a user will have only one role.
Hope this helps.
I'm have a requirment consisting of 7 roles in my database, each role has different attributes and want to maintain a single login table with username, password and role. So, is it a good practice to maintain a same login table for group of roles and saving all the other related details of the each role in a separate table based on their roles.
I am currently designing a database for a file sharing service. Every folder that is created on this service will have its own Table(Folder_) each Folder will also be added to a Table which will have the folders and their owners.
Is this bad practice? The reason being I have there are several features which I want to incorporate into this service which require me to have a table for each folder i.e permissions/different levels of access.
e.g The owner of Folder A has added 3 users with different levels of access to the folder User1, User2, User3.
User1 has view only access.
User2 has edit access.
User3 has full access.
The reason I can't see another of doing it except for creating a table for each folder is, if I had a Table of File/Folders with the usual attributes where could I put the users who have access to the folder and their level of permission? Also how would User1 view what folders they have access to with a big search of the entire database etc
The reason I dont think it can be good practice, is the amount of tables that will be in the database?
I would suggest a single table for folders, another table for users and a third table for user folder permissions. If you are making many tables that all have the same columns, you are probably not normalizing correctly.
Table: Folders
FolderId
FolderName
OwnerUserId -- references Users table to identify the owner
(additional columns as necessary to describe a single folder)
Table: Users
UserId
UserName
(additional columns as necessary to describe a single user)
Table: FolderUsers
FolderId -- references Folders table
UserId -- references Users table
Permission -- (ViewOnly, Edit, Full, etc)
The FolderUsers table is called a junction table, it allows a many-to-many relationship between Folders and Users, just add a row for each folder/user combination.
Is representing user permissions better in the user table or better in its own permissions table?
Permissions in User table
Putting permissions in the user table means making a column for each permission in the user table. An advantage is queries should run faster because no joins are necessary when relating users to user permissions. A disadvantage is that having many permissions columns clutters the user table.
Permissions in Permission table joined to User table with many-to-many relationship
Doing it this way cleanly separates out the permissions from the user table, but it requires a join across two tables to access user permissions. Database access might be slower, but database design seems cleaner.
Perhaps keeping permissions in a separate table is better when there are many permissions. What are other considerations in making this decision, and which design is better in various situations?
The standard pattern for access control is called Role Based Security. As both the number of users and the number of different types of permissions you need grows, the management of your user-to-permissions links can become increasingly difficult.
For example, if you have five administrators and fifty users, how do you keep the permissions of each group in synch? When one of your users is promoted to an administrator, how many edits do you need to make? The answer is to create two intersections: users-to-roles and roles-to-permissions.
This solution is described (including entity relationship diagram) in my answer to this question.
Your first approach is feasible when the number of different roles/permissions is relatively small. For example if you only have two types of users: normal and admin, a separate table looks like an overkill. Single is_admin column is sufficient and simple.
However this approach does not scale once the number of roles exceeds a few. It has several drawbacks:
user table becomes very "wide" having a lot of empty columns (wasting space)
adding new role to the system requires altering user table. This is cumbersome and might be time-consuming for large user database
listing user roles requires enumerating over all columns, as opposed to simple database query.
I am in database design development phase. Application will work with large number of users (LARGE :))
I designed 80% of database but I have one Users table which is connected to everything else:
Users {UserId, FirstName, LastName, Username, Password, PasswordQuestion, PasswordAnswer, Gender, RoleId, LastLoginDate etc etc}
I saw asp.net membership database structure where Users and Membership are two tables. My questions are:
Should I use one users table with all users data in it or more tables?
If answer is 'more tables', what tables to use? Any advice on how to structure relation between those tables?
This is sample relation that I have, and trying to improve. I don't understand why user and userChild are separated tables?
How many tables you need depends on your modeling needs.
For example if you include the RoleId in the Users table then you'll only be able to assign one role per user. Is that what you want?
Otherwise, if you have a separate table linking users to roles, you'll be able to assign more than one role per user.