Quick question as relates to database.
Where would you store the value of "UserVerified"? (The one that occurs after the user has checked his email and clicked on the "Verify" link with the hash value at the end).
Would you store it in the User table? (Along with username, hash) ?
Or in the UserProfile table (along with first name, last name, email, phone, etc) ?
Please note that both tables will always contain 1 entry for a user, such that when a user is created, automatically a userprofile is created as well.
This is all up to your preference. I would figure out what you want it to be more related to, the account as a whole, or to the email address. If it is more related to the account and determines if the account is active, then store it in the User table. If this is more related to the email address and that it is verified, then store it in Profile table.
Again though, especially since the tables are 1:1, it doesn't really matter other than relation and readability.
Related
I have 3 user roles, ADMIN, GURDIAN, STUDENT. I have the GurdianProfile & StudentProfile tables linked using uniqueID's (i.e. GurdianID, StudentID). That is the link that connects the 'gurdianLogin' tables and 'studentLogin' tables.
My Question is: What is the standard way to structure a 'User Login' table? Should I use one single table to store different types of users (i.e. all the 3 types of users) ? Or is it better to use 3 different tables to use different type of users on a single database ?
What is the best-practice and strategy or recommendations ?
Note: I'm using ColdFusion, MySQL
If you have a single logon point, I would see having credentials spread across 3 different tables as a flaw because if you ever added a 4th user type, you would then have to update your login system to incorporate the new user type. So, i would go with having a single user table, and then if you need separate tables for your guardian/student/admin profiles, link them to the user table.
_User_
id
email
username
password (this better not store the password in plain text..)
_GuardianProfile_
id
userid (links to user table)
(GuardianProfile fields)
_StudentProfile_
id
userid (links to user table)
(StudentProfile fields)
_AdminProfile_
id
userid (links to user table)
(AdminProfile fields)
If the columns in the three profile types are the same, it might make sense to condense that to one table with a type column.
I use one table to store login details - userid (primary key), salt, passwords, usernames, email addresses.
I authenticate against this table. I then use other tables linked by the userid to store contact information or other important data.
For restricting access to certain parts of the site I create other tables such as user, adimn, superadmin and store the userid's. I then test against the desired table to see if the userid is present and thus determine access to a page/area.
I am creating site and there are 3 roles on it. Administrator, Teacher, Parent. User with any role has access to site, but 1 role has full access, teachers can only put marks for students, parents can only watch these marks.
I understand how to separate roles into scripts. Just save some parameter depending on what database would return when I check login and password.
So! Administrator has only login name and username. Also it is possible to store information about how to contact the user to make system more user-friendly. That's all.
Teacher has firstname, lastname, midname (father's name), address, phone etc. And it must have login and password fields...
Parent has Firstname, Lastname, Midname only. And sure somewhere I should to store data about login and password.
So should I just check this tables 1 by 1 and depending on table I will find $login and $password I inputted in I will return role? I don't think it is a nice idea. Suggest something else please.
What I think to do. I think that it would be not very bad idea if I will create 1 more table like users where I will store: id, username, login, role, user_id (need to think about it). The problem is user_id. How exactly this table will be connected to others? For example user_id` would be 1. 101% there would be 1 row with such id.
I want to ask about exprience of your self-build systems. May you suggest something please!
You're right. It doesn't make sense to have different tables for users. I would recommend you to store authorization and personal data in separate tables. And of course you'll need additional table for roles:
The idea behind this scheme is to keep thin users table for fast authorization. If authorization was successful, than you should check permissions from roles or get personal data from user_data tables.
Look at this sql-fiddle for DDL.
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
I've a problem deciding where to place a certain table field within my database.
The database is for a classified ads website.
I want registered and non-registered users to be able to post ads. If an unregistered user posts an ad, the site should ask him for the contact phone, if the user is already registered, then the contact phone stored in the users' table should be used.
Now my question is, would it be possible to store the contact phone for both registered and unregistered users in the same table field?
If so, where should that field be put, in the Classified ads table, or in the users' table (noting that each user within the table has a unique Id, thus, filling the users' table with unregistered users just to get their contact phone will just fill the table with useless data)
Thanks in advance !
well you can put the phone field in the ads table, with a is_registered field inside. Then via php you check is_registered and then you know where to search for phone number.
Regards
You can store unregistered users' phone numbers in the same column of the same table, and you probably should. It makes the transition from unregistered user to registered user dead simple--you don't have to move or re-enter phone numbers. And if any user changes phone numbers, it only has to be updated in one place. (Do you know how many people accidentally drop their cell phones in a toilet every day? It's staggering.)
If you're now relying on the presence of a phone number to identify registered users, you'll need to fix that first. (I don't think you're doing that, but if you are, fix that first.)
You said
filling the users' table with
unregistered users just to get their
contact phone will just fill the table
with useless data
If it's useless, don't store it. If you need to store it, it's not useless.
You can always delete unregistered users when their classified ad terminates. But . . .
Does it make sense to require a contact phone number instead letting the user choose to leave either a phone number or an email address? Personally, I prefer to use a throw-away email address for things like this.
I would look for flexibility in your design, but if your logic treats users mostly independently of whether they are registered or not, I would use the same table and just complete the rest of the user's data for the registered ones. I wouldn't store user data on the ads table, even if only for clarity of data organization.
I guess your registered users will all have a username and password, so you can just check the presence of these to know if they are registered or not. If you don't want to change your logic in the future you should choose this distinction carefully of course.
A different approach: Why not making registration so easy that it makes no sense to have unregistered users? I you are already asking for a phone number in all cases, just add a password field or generate one automatically and you have all your users registered.
I would ask for an email so you can send the password and perhaps ask for account verification (now or in the future).
I was wondering if it would be better to have things like perishable_token (used for account validation and resetting of passwords), banned (boolean to check if the user is banned), email_verified (boolean to check if user's email has been verified) in a separate table in the database, as it will rarely ever be used.
Also, I have my applications set so that a user logs in with a password and email address. The email address will only ever be displayed on the User Edit page, and the password will never be displayed anywhere. As these two things will pretty much only be used when the user logs into their account, is it necessary to have them in the main User table in the database? Or would it be better (faster?) to have them in another table?
The user table will have -many- other things that will be displayed on all pages and will need to be checked often (things such as a user's "money" "credits/points" "logged_in?" "badges" etc).
Since your user table has many other things, it seems unlikely that you would get any performance improvement by moving those five columns (which seem not to contain much data) into a separate table.