I finally got permission to redesign our database (yay, everybody cheer)!
One of the problems that I need to overcome is user login.
The way the database is currently designed, there is a User table, with a 1:n relationship to UserStaff (user can have multiple staff - think of a manager). There is also a completely unrelated Customer table.
I need to create a table to consolidate the login so that all of these people (User, UserStaff, and Customer) can login to the same area, but each of these tables above has completely different information inside and different relationships to data.
How/where should I start moving things around to get this to work?
You could create a "Login" table containing "loginID", "email", and "password" fields. Each of the other tables (User, UserStaff, Customer) would also contain the "loginID" field. Then at login-time you could SELECT from the login table, and (left) JOIN on loginID to the other tables to get your user's data.
Related
I'm new to MySQL and databases, and this question is more about best practices than exact code.
If I want to create a database that let's users register an "account" so they are then able to access and track the value of virtual goods in a video game, including selecting items from a list and marking them (thus requiring the choices to be associated with their account), Is it better to store the users choices in the same table that holds their username/account-info? Or should the information be stored in a separate table with a reference to the associated account?
Or should I create a table for each user, instead of having one for registration/account info, and another for data, etc.?
Does the best practice for this vary with the expected number of users and/or amount of data?
Is there a way to set it up that allows for handling growth from 2 or 3 users to hundreds?
The answer is to create one table for accounts, one table with choices that are referenced to that account with some type of token.
There's no reason to create a new table for each user. You should have one table, and differentiate between the users using the data in the table (e.g., the userid, the username, etc).
I need to make a user table in an education database where a user can have the following profiles:
1. Admin
2. School Admin
3. Tutor
4. Student
5. Parent
6. School Teacher
Now, the question is weather to make separate tables for each profile and use a key in the user to table to link with profile table or keep all in one and add a profile key to identify the type of user. Everyday new users are added in the database so its a growing database.
The queries which are run to fetch the data are specific to the profile. For example, the data will be fetched for one profile at a time. But, what about the cases where we need to get all the teachers of a student or all students of a teacher? In that case I will have to store the id of the student in the tutor and teacher table. What is the optimized way of going about it?
I will suggest to make separate tables for profile and use a key in the user to table to link with profile table (if profiles are pre-configured)
if profiles are dynamic then you have to take care in your application like check profile exists or not, if not exists then first insert into profile table and then insert into user table. This may affect INSERT performance.
to get all the teachers of a student or all students of a teacher, you have to use self-join
I would like to get some advice from you about best practices in user role management.
I would like to create an application where user register and will have different roles. Now the obvious thing is, to create the users table and save the user data there like this:
users
id
userUUID
username
role
But I think about separated tables for different groups. So like:
admins
id
userUUID (-> foreign key users table)
accessRight1
accessRight2
subscribers
id
userUUID (-> foreign key users table)
etc
Does this make sense? So should all users, regardless of their role be in one database? And what is then about the specific information for different roles?
Thanks!
If your roles are rarely going to change that would probably work. But, you should always plan for change, and a more flexible option allowing you to add roles without needing to change your database schema would be something like this:
Users:
uid
user info...
Roles:
rid
name
UserRoles:
uid (FK to user table)
rid (FK to roles table)
In your code you could then check the UserRoles table to determine if the user has a given role and therefore should be allowed to do whatever.
Additionally, if you want to mix and match permissions for actions across multiple roles (i.e. both Admin's and Moderators have permission to delete posts or something). You could add another level with a Permissions table, and a join table (RolePermissions) linking that to the Roles table. You're access checks would become slightly more complicated then, requiring you to join the UserRoles table and RolePermissions join table to determine if a user has a given permission to do something.
Something like this:
SELECT *
FROM UserRoles u INNER JOIN RolePermissions p
ON u.rid=p.rid
WHERE u.ID=<USER> AND p.pid=<PERMISSION>
I'm designing a MySQL database with some tables for a clinic and I need three different user types: admin, medic and patient.
What I did was to create a table called users where its columns are precisely the common fields shared by admins, medics and patients (there is of course a primary key called id_user which auto increments every time a user is added).
Then I created three tables regarding the specific data for each user type: admin, medic and patient in which I have a field called id_user which is a foreign key to id_user in the table users.
When I tried to establish the foreign key constraint for the three user type tables, phpMyAdmin doesn't allow me to set ON DELETE as "SET NULL" (I think that would make sense because if I delete a user from the users table then it should automatically set the fields as NULL in the medic, admin or patient tables, right?) and gives me the error "relation has not been added".
Doubt 1: What's happening here that I'm not aware of?
Doubt 2: Should I forget this way of relating tables and simply add the specific fields for each user type in the users table although some users will have some fields set as NULL?
Here is an image illustrating my database:
You should use Cascading Deletes instead of setting fields null, if you delete a user you want them gone if you null out the data you'll just have tables filled with nulls.
Also from what i understand you created 3 tables for each of the permission levels if this is the case you should maybe handle that in code with conditions checking the permissions level
I want to create a DB for a PHP Mailer App, The program will allow user to Login, Once user logs into the system they will be able to write Send to: email, Subject, from and select HTML template form drop down menu. I have an gd understanding of how to accomplish these but because I am not so good with designing a Database I decided to ask for help here.
So I have identyfied 3 tables :
Users[id, firstname, lastname, email, password]
Message[id, send_to, subject, template_used, from, date, ip_address]
Template[id, temp_name, temp_html].
I am struggling with the relational database concepts but this is how I see it:
User 1..* -----------1..* Message, Message 1..1 ----------- 1..1 Template,
Template 1..1--------1..* Users
Not to sure about these relation and if the relation between User and Message is correct is it this a problem where two tables are 1..*.....?
A good database in relational model requires the tables at least to conform up to the third normalization rule (3N).Please read something about 1N 2N 3N.For now, that is, the existing relationships should be reduced to (one to many). There cannot be many to many if you expect a wonderful RD.
Lets analyse the relationship of user to messages tables:
Situation 1:
One user can have many messages,i.e (user ----messages) ----(one to many)
One message can be for many users, I.e (message -----users)-----one to many
This implies messages to users has many to many relationships. By normalization rules, this is not correct (For the sake of referential integrity).
This can be avoided by introducing another table that would act as intermediary , call it (messageuser). This table will contain the primary key of messages foreign key and user foreign key as it primary key thus composite key.
What therefore do we notice:
(Figure: simple illustration-not standard)-sorry i could not upload the picture to show you that as guided by the site's rules and policies.
We now have three tables with two relationships with each one in the form of (one to many).
i.e user to usermessage (one user has one message with his id) and message to user(one message is send to one user with particular id).
Is that not great.