okay so I'm developing this website for my capstone class, it's a ticket reservation system. I'm using phpmyadmin on wamp server. My question is, at any point of time many users will be on my website.
They register or login, and according to their status ( being a Director or Audience) they can reserve a number of seats. So suppose if 2 users are on my website, one as a director and the other as an audience. How can I know which user is which?
When they register, the status is stored in the database, but how can I know which user has which status that are both on my website?
Thanks
From my assumption if both User has different user name and password from these information you can find login user status.
I will suggest to create a mapping table of Roles with User.
For example, User, Role and UserRoleMapping Model.
User ( id, username, FirstName )
Role ( id, role )
UserRoleMapping ( user_id, role_id, status )
Here when User makes an registeration, then as per its role create an entry in UserRoleMapping Table.
Then use of the view to display the list of UserRoleMapping, use their id to display their name and role. Make use of filter in tabs for different role by ordering with respect to created datetime.
To make more advance, you can also display the number of success login, login failure, latest login etc.
Related
I'm having a hard time to create a schema for my CMS. It is a reservation system for hotels/resorts. I have two users and two connected websites, one for the client and the other for hotel/resort owners (CMS). The owners should create his own account and using that account he can add more than one hotels/resorts, the problem is the owner should be able to add an admin or another user that can access his account so that in case he would not be able to update his reservations he can ask his assistant to update the it. My current schema is like this
Users
id
name
bday
age
and other personal details
then..
Hotels
id
user_id
name
rooms
and other details
When the owner logged in to his account Im getting all his hotels using this query:
SELECT * FROM hotels WHERE user_id = <owner id>
Im thinking of just adding another column like (user_id_2) and (user_id_3) in hotels table. but i don't think that's the right way because that would limit the number of admins. What do you guys think?
I would like to create project and following is scenario :
Database tables:
Table first : Company
Table Second :Employee
when superuser create company then i put information in company table like company name, user name and password.
Then with these username and password company login and enter its employee like name, gender , phone no etc plus username and password for employee so that employee can login as well with its employee rights.
confusion is that when superadmin create new company then it enter values in company table and when company create emplyee account then i enter value in employee table. So on login screen how i can check its superadmin, company or employee so that i can get information from that perticular database table.
Can you guys help me to create database for this scenario. how i can manage what should i use join , view or.....
thanks
Your database structure is correct as you're putting relevant information in each table. E.g. Company's data in company table and Employee's data in employee table.
What you need to do is when someone logins from platform add a extra parameter along with credentials for the type of user.
There are couple of solutions for this,
Create two separate pages for Employee and Company's login.
Have single login page for both of the user having selection box for the user type.
I have four different types of users login in to my website like admin, superadmin, company, and employees. Each of them have different set of pages to see but some common pages as well. Now I am having four different tables to manage them with same login screen for admin and superadmin. When either admin or superadmin logs in I will go and check two tables one by one before giving access. I have a separate login screens for company and employees. Is this the accepted way of doing it?
Actually, I want this to be changed to a single table with all users in it and a role table to differentiate the roles. I believe a four-table concept is really bad. I can't simply make it to one table because the previous developer had a habit of saving user comments and user activities in text files which is used on website.
Am I right in the way I think that a four-table login system is bad? Is storing logs in a text file that are directly used in website a good idea or not?
You have 4 tables? Just use one user table and a field that can either be 'admin', 'superadmin', 'company' or 'employees'. Then you can have unlimited types of accounts. (I would do number codes like 1,2,3 or 4 instead of string codes or ENUM type field).
But yeah, your single table idea is fine. If you want a role table, do a foreign key to your role field and link it to your role table. You can have a single login too instead of different ones for different users and check for privileges based off that foreign key value.
Here's my suggestion,
Instead of using four tables for your users, it would be better to use one.
You can create you basic user table like this (change rank to what suits your site/script):
ID username password email bla bla bla rank
So instead of using four tables, you can make your PHP script check if the user has the desired access level.
Here's a simple function to protect pages from lower access level users:
function required_level($level){
$user_level = mysql_return(mysql_query("SELECT $rank FROM `Accounts` WHERE `user_id` = $user_id"));
if($user_level<$level){
header("Location:index.php");
}
}
Then on each page you want to protect from lower level users accessing it. You can just call required_level(4); and the page will only allow users with this level or over to access the page.
Example:
Bob is a employee so he has a user rank of 1,
Joe is a superadmin so he has a user rank of 4
Both users login normally, and both try to access admin.php.
admin.php starts with required_level(4); so Bob would be redirected to the home page (you can also pass an error) but, Joe would be bale to access this page because his rank is the same or above what is required to access this page.
So, here's my super long explanation on what you can do! I hope this helps and gives you some ideas on how to make your user tables better and easier to create protect pages :)
First of all, you can do the whole thing with a single table. In that table you should have fields like username, password, typeofuser and other necessary information.
Retrieve user information like:
$username = $_POST['username']; //Retrieving a username from HTML login form
$row = mysql_query(sprintf("SELECT * FROM table WHERE username ='%s'", mysql_real_escape_string($username))); //Retrieving a row from the database
$res = mysql_fetch_array($row);
$type = $row['typeofuser']; //Retrieving whether it is administrator, super administrator, user, etc.
if ($type == "admin")
header(Loction:adminpge);
Similarly, you can check any type of user and can redirect to another page.
I already have a simple registration system in place using php and mysql. It operates well enough. However, when people visit my site and register, I would like for them to register as part of a particular group. So, I was thinking that registration would happen like this:
Visitor lands on index.php, clicks on "Group Registration" link.
Visitor supplies group name and group password. [A new table is created for that group where all user data will be stored for that particular group]
Visitor then is prompted for typical registration data--name, email, etc.--and that data is stored in the newly created group table.
Any subsequent visitors associated with that group would click on "User Reg"
The visitor would be prompted for group name and password
If correct, then he would be prompted for typical reg data, to be stored in his group's table.
What I don't know how to do is implement the group authentication prior to allowing user registration. Can someone help me with that?
If the visitor is entering a group name and password, then you can authenticate the same way you are doing the users. You just need to first ask yourself if the group name needs to be unique or the group/password combination.
As for your idea to add a new table for each group, that is a bad idea. Imagine if you have 100 groups. Then you will have 100 tables just for groups. If you get up to 1000 groups, then you will have 1000 tables. Try managing that. It will get really frustrating really fast. Instead, what you should do is to first create a "Group" table with all the associated data (group name, password, etc). Then add a field to your User table that will hold the associated id from the Group table. That way, whenever you look up the user, you can easily check what group the user is in simply by joining the two tables rather than trying to figure out what table to look at as in your original plan.
What you want to end up with is a table for your users and another (single) table for your group information. The user table will have a foreign key field to link it to a group. When a user joins a group, you will enter a value in that field. Users not in groups will have a null value in that field. If users can create groups, they will simply be adding a new row to the groups table.
If your users can be in multiple groups, set up your tables like this.
USER
- id
- username
- password
- etc...
GROUP
- id
- name
- password (?)
- etc...
USER_GROUP_CR
- fk_user
- fk_group
The USER_GROUP_CR table is a "cross reference" or "link" table that will allow you to create a many to many relationship. This way you can have users in multiple groups without creating extra tables. When a user joins a group, add a row to the USER_GROUP_CR table with the id of the user and the id of the group. You can query this table to find out which groups a user belongs to, or to find out which users are in a group.
You should not create a new table for every group.
I'm going to allow companies to register on my website and create job listings.
I'm currently approaching the problem by creating a Company table with Name, Logo and Password fields. Then when a person registers he can say, "I belong to X company"; at this point, I'll request the password written in by the initial registrator. If she/he enters the correct password then he is given permission to create job postings in the name of the company.
Why I'm doing things this way:
If I just put everything inside of the Company table, every new user would have to create an account and I'll have redundant information, CompanyName, Logo, etc.
And if I do things without a password, anyone can post a job opening under a companies name and that's just wrong.
Care to share some input? Am I doing things wrong? How would you do it?
I would do "jobs requests" like Facebook's friend requests and if the user really work in that company, the company manager just has to login and confirm it.
Database Normalization.
Create a separate Users and Companies table. Can one user post for multiple companies? if so, you need a many-to-many relationship (which requires a third table to keep track of the relationships). Otherwise, a one-to-many should work.
You should create two tables:
Company:
- id
- logo
( - name, etc )
User
- id
- companyId (foreign key to Company.id )
- password
( - username, etc. )
This way a User is a child of a Company identified by companyId. Now, if a user logs in, you can identify what company s/he belongs to by finding the Company corresponding with the companyId. Now you have a password per user, and a company per user.
And like Jimmy says, if you need Users to be able to be part of more Company's you would get:
Company
- id
- logo
User
- id
- password
Company_User
- companyId (foreign key to Company.id )
- userId (foreign key to User.id )
in my opinion you should create table like
Employers:
eid(pk)
logo
Username
Password
profile
etc....
JobSeekers:
jid(pk)
Username
Password
etc...
JobPosts:
id(pk)
eid(Fk to Employers.eid)
JobTitle
Specifications....