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....
Related
In an application I've been building, I have a users table. The users represent a firm's staff. I also implemented a role/permission system. Permissions are assigned to roles (staff, manager, director, etc.), and roles are assigned to users. Permissions prohibit the use of certain actions in the app.
Now, I'm introducing another user type: customer (will also be able to log into the app). The customer fields are different from the user fields, so I can't store the customer information in users table (and create a role for customers).
(Normally, just creating a customer role for the customers and store the custumers in the users table would be fine, but since the fields are different, I don't think that's an option.)
First, I thought about creating a seperate table for the customers, but I'm not sure if that's okay, because when someone tries to log into the app, I have to check two tables (users and customers) for the log-in credentials. What if I introduce a third user type? Check three tables? That doesn't seem practical/efficient.
So I thought about seperating the log-in credentials from users, and ended up with three tables:
users will hold log-in credentials
staff will hold staff meta/profile information
customers will hold customer information (same as staff)
This way, I can introduce many different types of users. And if I know what I'm looking for, I can get the record. For example, say I want to get/query a staff, I can just do:
SELECT * FROM staff
JOIN users USING (user_id);
The problem is how do I query users when I don't know what I'm looking for? I mean, the logged user can be a staff, customer, etc. I need to do something like this:
SELECT * FROM users
JOIN [specific_table_name] USING (user_id);
How do I know which type of user just logged in? I could store the user type (the target table name?) in users, but will it help in a (single) query? I mean, find the user in users (using credentials), and then join the user information from another table (staff, customers, etc.)?
Currently, I'm thinking about doing two queries. First is to get the user (credential) record, and the second is to get user (say, profile) information (using a field type from user record).
Of course I'll be doing this in PHP. For example (not real code):
$email = "someone#example.com";
$user = get_user($email); // SELECT * FROM users WHERE email = "someone#example.com"
switch ($user["type"]) {
case "staff":
$user = get_staff($email); // SELECT * FROM staff JOIN users USING (user_id) WHERE email = "someone#example.com"
break;
case "customer":
$user = get_customer($email);
break;
// ...
}
// how it's done doesn't really matter. the thing is "type" needs to be checked to get the corresponding user info
Is this best way to handle this? Is there a way to make the queries in SQL (without resorting to PHP)? Like JOIN after WHERE? Or make two queries in one (save the first query result, and use a column value from the first result as a table name in the second query)?
Mentioned tables:
I'm still researching, and I found out that what I'm doing with the tables is called (?) "Class Table Inheritance". It seems clever for non-login related entities (when going from child to parent; e.g. staff -> user), but in reverse (parent to child, e.g. user -> staff|customer|etc.), it seems problematic. Since I figure these things as I go, I'm stuck at the moment.
One solution that just (while typing) occured to me is to use different log-in forms/pages specific to user types. The form/page could let me know the user type beforehand, but I rather not use this method. So, single log-in form for all users.
I'm calling users as the base/parent table, and the stuff, customers, etc. as the child tables, because first insert happens at users, and child tables use user_id from users.
You could create a union and use an alias in the query to define different fields mapping for the same name, if there is no field in one table you just cast the alias for an empty field:
SELECT (staff.name) as name FROM users
left JOIN staff USING (user_id)
UNION
SELECT (customers.first_name) as name FROM users
left JOIN customers USING (user_id);
If the userId is a PK/FK it will be only returned by one table.
I would set all users login info and email to the parent table (customers and staff) and two tables with foreign id key for other data, with users.type as you suggested. It could be done with one query, too and Switch condition is not needed:
SELECT users.email,users.type,staff.field2,customers.field3 from users
LEFT JOIN staff ON(users.type='staff' and users.id=staff.uid)
LEFT JOIN customers ON(users.type='customers' AND users.id=customers.uid);
I'm trying to make an Address book with different users in which they can log in with their username and password. And they can store the information like contact id, first name, last name, phone etc. I want each user to have his own address book.
Can someone please explain how I create different address book for different users.
Thanks a lot.
Create a database. take a primary id to each user or provide unique id.Then create another table fill the fields that you want(address book).Match the user who logged in and and with that another table(foreign key relationship).
When you login ..it checks with db then allows.After that you have to use insert ,update keywords for further process to put data in db.That particular unique id/primary key is used to fetch the related data(address book fields) of that user.
It is actually not a good question for StackOverflow but I will still roughly explain it to you.
You will need two different tables for this. The first one will be used for login details and the second one will record user's address book.
For example:
Table auth will have 3 columns id, username, password
Table addressBook will have contact id, first name, last name, phone etc and also have one more which will be called userID
Whenever any user eneter the data in addressBook their userID from auth table coloum id will be stored along with it. Now you can display their own data to the users.
If you have anymore question ask in comment here.
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.
I'm building a school project and my idea is to have a site where you can register an account, add a couple of users to that account and then calculate their monthly shared expense debt, e.g. User A pays 500 on groceries and user B only pays 250. This gives User B a debt of 125 to user A that month.
My problem is that I want to separate the accounts with the users. Now I have a setup of a table called Accounts with email and password and then I have a users table with particular user information. I want several people to be able to log in to the same account using different credentials.
Users table
ID, Name, Account_id etc.
Accounts table
ID, Email, Password, date_added, date_updated etc.
What is the best approach of doing this? Is it to have a cross-table called UsersForAccounts or do I specify several account_ids in the Users-table?
You wouldn't think of it as several users on one account. You would think of it as several user accounts that share a common group setting.
So you have a user's table as you may expect - each with its own values for that person, obviously.
Then you have a related table that shares the details for the group. Let's use a fraternity or something as an example.
SO you have Pi Phi as a group name. Within that are Users A, B and C.
A very very basic table structure might look like this:
Users: id, email, password, name, group_id
Group: id, name
So a user would - by this setup - have a relation to only one group. You could make that a relational table so a user can have many groups if you want.
The general idea here is that you use the group as a separate connection point to the user and not necessarily several users that access with the same account.
If that is unclear, feel free to ask and I may update
You can use a structure such as in the Users Table:
ID, Name, etc.
And in the Accounts table use simplest:
ID, Email, Password, date_added, date_updated, User_ID, etc
This is called Many to One relationship, and is ideal to your case.
A small tip i can pass to you is use LOWERCASE to ALL your fields, or in special to the first character of the name of the field, with an excerpt for "ID" (that is only a acronym (or similar) to Identification)
In an basic example, the Users table has the fields:
ID, name, etc.
And Accounts table the structure above:
ID, email, password, date_added, date_updated, user_id
This can't help much in a short time, but it can help you, and very much, at use of the database with PHP.
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.